Меню
Что нового?

кто тормозит железо - постгресс или скрипт

Alexandre

PHPПенсионер
проверь, чтобы кеширование вывода в ПХП было
Нажмите для раскрытия...
используется кеширование
Выясни что куда расходуется, поиграйся с vmstat
Нажмите для раскрытия...
стараюсь понять что к чему...
нагрузка на сегодня на самый посущаемый сайт
10:00 432 (посетителей)
11:00 469
12:00 431
13:00 448
как видно, не так уж и много
пятнадцать минут назад на сайте сидело одновременно 60 посетителей.
Код: 
last pid: 12529;  load averages: 41.02, 47.76, 47.70                                                               up 47+06:11:14  14:56:07
601 processes: 182 running, 414 sleeping, 1 stopped, 4 zombie
CPU states:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 1153M Active, 325M Inact, 436M Wired, 93M Cache, 199M Buf, 3496K Free
Swap: 4097M Total, 240K Used, 4097M Free

  PID USERNAME      PRI NICE  SIZE    RES STATE  C   TIME   WCPU    CPU COMMAND
12529 moscowout      64   0  2564K  1724K CPU2   2   0:03 36.67% 10.84% top
91513 root           63   0  3472K   560K RUN    1  30:06  4.83%  4.83% find
  619 pgsql           2   0   277M 16428K select 3  28.6H  2.93%  2.93% postgre
  558 pgsql          57   0   283M 49040K RUN    3   0:44  2.29%  2.29% postgre
11800 pgsql          56   0   280M 78892K RUN    3   0:02  2.10%  2.10% postgre
 5337 pgsql          55   0   283M 49592K CPU1   1   0:26  1.90%  1.90% postgre
11887 pgsql          54   0   280M 70048K RUN    3   0:02  1.66%  1.66% postgre
12169 pgsql          55   0   280M 45804K RUN    3   0:01  1.60%  1.56% postgre
 3310 www             2   0 22580K  7352K select 1   0:05  1.37%  1.37% httpd
12148 pgsql          54   0   280M 46028K RUN    3   0:01  1.20%  1.17% postgre
12344 pgsql          58   0   278M 19060K RUN    3   0:01  1.33%  1.17% postgre
12085 pgsql          54   0   280M 52148K RUN    3   0:01  1.13%  1.12% postgre
12181 pgsql          -4   0   280M 41736K semwai 3   0:01  1.15%  1.12% postgre
12174 pgsql          54   0   282M 31348K RUN    3   0:01  1.05%  1.03% postgre
12239 pgsql           2   0   278M 48556K sbwait 3   0:01  1.07%  1.03% postgre
12292 pgsql          55   0   278M 19744K RUN    3   0:01  0.94%  0.88% postgre
12339 pgsql          56   0   278M 20500K RUN    3   0:01  0.88%  0.78% postgre
12319 pgsql          56   0   278M 21552K RUN    3   0:01  0.75%  0.68% postgre
12340 pgsql          56   0   278M 20600K RUN    3   0:00  0.72%  0.63% postgre
 7931 www             2   0 21048K  7268K poll   1   0:03  0.59%  0.59% httpd
12067 pgsql          -6   0   280M 38812K biord  1   0:01  0.59%  0.59% postgre
12335 pgsql          55   0   278M 19948K RUN    3   0:01  0.66%  0.59% postgre
12361 pgsql          56   0   278M 19128K RUN    3   0:00  0.69%  0.59% postgre
12380 pgsql          58   0   278M 15864K RUN    1   0:00  0.72%  0.59% postgre
12371 pgsql          58   0   278M 16388K RUN    3   0:01  0.64%  0.54% postgre
 5902 www             2   0 21824K  7372K poll   2   0:04  0.49%  0.49% httpd
12379 pgsql          -6   0   278M 19500K biord  0   0:00  0.60%  0.49% postgre
12389 pgsql          57   0   278M 17260K RUN    3   0:00  0.60%  0.49% postgre
98090 www             2   0 21752K  6616K poll   1   0:08  0.44%  0.44% httpd
 1722 www             2   0 21836K  6364K poll   0   0:06  0.44%  0.44% httpd
12308 pgsql          54   0   279M 17056K RUN    3   0:01  0.48%  0.44% postgre
12346 pgsql          56   0   278M 19184K RUN    1   0:00  0.50%  0.44% postgre
12433 pgsql          57   0   277M 11996K RUN    3   0:00  0.63%  0.44% postgre
12390 pgsql          57   0   278M 17800K RUN    3   0:00  0.55%  0.44% postgre
12324 pgsql          55   0   279M 21948K RUN    3   0:01  0.43%  0.39% postgre
12312 pgsql          -6   0   278M 22268K biord  3   0:01  0.43%  0.39% postgre
12320 pgsql          54   0   278M 20876K RUN    3   0:01  0.43%  0.39% postgre
12366 pgsql          56   0   278M 18832K RUN    1   0:00  0.46%  0.39% postgre
12382 pgsql          57   0   278M 17316K RUN    3   0:00  0.48%  0.39% postgre
98158 www             2   0 21900K  6252K poll   0   0:07  0.34%  0.34% httpd
 3034 www             2   0 21848K  6192K poll   3   0:06  0.34%  0.34% httpd
 2894 www             2   0 21924K  5736K poll   1   0:06  0.34%  0.34% httpd
 4338 www             2   0 21968K  6136K poll   0   0:05  0.34%  0.34% httpd
-~{}~ 31.10.05 14:43:

а вот сервак умирает ?)

-~{}~ 31.10.05 14:44:

Код: 
%vmstat
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us sy id
65 217 0 2050568 107324  621   0   1   0  35 224   0   0  568  628 858 14 16 69
 

Steamroller

Новичок
Ну это на deadlock очень смахивает.
Надо всерьез работать с запросами, добиваться чтобы они моментально выполнялись. Особенно записи.
 

Alexandre

PHPПенсионер
Код: 
%sysctl -a | grep "hz"
kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, stathz = 128 }
%vmstat -i
interrupt                   total       rate
em0 irq16               800493973        195
ahd0 irq18              588164063        143
ahd1 irq19                     15          0
ata1 irq15                      6          0
fdc0 irq6                       1          0
clk irq0                408657379         99
rtc irq8                523035853        127
Total                  2320351290        567
Ну это на deadlock очень смахивает
Нажмите для раскрытия...
пользовательская часть почти не имеет команд INSERT / UPDATE, одни селекты
в чем может быть причина deadlock
 

Steamroller

Новичок
пользовательская часть почти не имеет команд INSERT / UPDATE, одни селекты
в чем может быть причина deadlock
Нажмите для раскрытия...
Если не пишется ничего в базу, то это что-то другое.
Может просто запросы поступают быстрее чем успевают обработаться, и в итоге по нарастающей все тормозит.
Может имеет смысл попробовать жестко ограничить число Апачей в конфиге, 50-ю например. (Хотя без nginx этого лучше не делать).
 

Steamroller

Новичок
Процессов меньше станет, памяти меньше будет расходоваться, значит больше памяти на кеширование, значит быстрее будет база на запросы отвечать, значит меньшим числом процессов можно будет нагрузку держать и т. д. :)
 

Screjet

Новичок
Еще проверь hyperthreading (если есть), если включен = то выключи (глюк fbsd).
 

si

Administrator
судя по тому что в top в поле C цифры от 0 до 3, значит HT включен

-~{}~ 31.10.05 18:24:

а выключить его надо в биосе имхо
 

Alexandre

PHPПенсионер
вопрос может быть не в тему, а явно незакрытые коннекшены pg_сlose() могут тормозить.

т.е. могут из-за этого множится процессы, а запросы с новых страниц стоят из-за этого в очереди??
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Это не дедлоки и не очередь, я и то, и другое видел неоднократно, а ту хрень которую ты тут показываешь --- в первый раз. Это какой-то косяк с системой, попробуй действительно выключить HT.
 

si

Administrator
Alexandre
когда скрипт закончился и если был не pconnect, соединение должно закрываться. посмотри в pg что за конекты и чем они занимаются.
 

neko

tеam neko
по поводу semwait
откуда такая уверенность что это не locks?

надо сделать так -- когда оно подвисает в semwait, выполнить запрос типа такого:
Код: 
select pid, relname, mode, granted
from pg_locks l
inner join pg_class c on l.relation = c.oid;
это покажет на каких таблицах висят локи, там где granted = t -- значит блокировка получена, иначе -- блокировка ожидается.

второе что нужно сделать это включить лог медленных запросов.
делается это выставлением в postgresql.conf:
log_min_duration_statement = 5000
log_duration = true
min_duration_statement выставляется в милисекундах
подобрать его надо самостоятельно исходя из предполагаемой скорости работы и запросов

дальше у меня такой вопрос
вы вообще кластер настраивали?
postgresql.conf меняли с дефолтных настроек?

-~{}~ 03.11.05 06:27:

91513 root 63 0 3472K 560K RUN 1 30:06 4.83% 4.83% find
Нажмите для раскрытия...
супер!!!
 

Alexandre

PHPПенсионер
когда скрипт закончился и если был не pconnect, соединение должно закрываться. посмотри в pg что за конекты и чем они занимаются.
Нажмите для раскрытия...
у меня pg_connect();

-~{}~ 03.11.05 11:41:

дальше у меня такой вопрос
вы вообще кластер настраивали?
postgresql.conf меняли с дефолтных настроек?

91513 root 63 0 3472K 560K RUN 1 30:06 4.83% 4.83% find
Нажмите для раскрытия...
настройками занимался админ хостера (best-hosting), но он говорит, что он все оптимизировал
Код: 
syslog = 2              # range 0-2; 0=stdout; 1=both; 2=syslog
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
# - When to Log -
#client_min_messages = notice # Values, in order of decreasing detail:
#client_min_messages = warning  #   debug5, debug4, debug3, debug2, debug1,
#   log, info, notice, warning, error
#log_min_messages = warning  # Values, in order of decreasing detail:
                        #   debug5, debug4, debug3, debug2, debug1,
                        #   info, notice, warning, error, log, fatal,
                        #   panic
#log_error_verbosity = default     # terse, default, or verbose messages
#log_min_error_statement = warning # Values in order of increasing severity:
                         #   debug5, debug4, debug3, debug2, debug1,
                         #   info, notice, warning, error, panic(off)
log_min_duration_statement = 1000 # Log all statements whose
                         # execution time exceeds the value, in
                         # milliseconds.  Zero prints all queries.
                         # Minus-one disables.
silent_mode = true           # DO NOT USE without Syslog!
# - What to Log -
#debug_print_parse = true
#debug_print_rewritten = true
#debug_print_plan = true
#debug_pretty_print = true
#log_connections = false
#log_connections = true
#log_duration = true
#log_pid = true
#log_statement = true
#log_timestamp = true
#log_hostname = true
#log_source_port = true
 

Alexandre

PHPПенсионер
это что весь конфиг?
Нажмите для раскрытия...
весь слишком длинный, какие секции выложить?

через 10 мин ссылку на конфиг выложу

select pid, relname, mode, granted
from pg_locks l
inner join pg_class c on l.relation = c.oid;
Нажмите для раскрытия...
Код: 
54788 | pg_class                        | AccessShareLock | t
 54654 | pg_operator                     | AccessShareLock | t
 54771 | pg_class_oid_index              | AccessShareLock | t
 54824 | pg_index                        | AccessShareLock | t
 54841 | pg_trigger_tgrelid_tgname_index | AccessShareLock | t
 54797 | pg_class                        | AccessShareLock | t
 54726 | pg_class_oid_index              | AccessShareLock | t
 54783 | pg_attribute                    | AccessShareLock | t
 54791 | pg_attribute                    | AccessShareLock | t
 54829 | pg_class_relname_nsp_index      | AccessShareLock | t
 54811 | pg_operator_oprname_l_r_n_index | AccessShareLock | t
 54549 | pg_class_relname_nsp_index      | AccessShareLock | t
 54828 | pg_attribute_relid_attnum_index | AccessShareLock | t
 54752 | pg_opclass_am_name_nsp_index    | AccessShareLock | t
итого 371 запись

-~{}~ 03.11.05 12:50:

есть два конфига - не знаю, который из них используется, как определить???
 

mar

Новичок
у меня тоже несколько вопросов + к нашему вчерашнему разговору по аське :)
- заработал ли сбор статистики (NB скрипт, который я давала (http://mar.nesin.spb.ru:8080/psql_query.html ) - это не дубликат лога медленных запросов log_min_duration_statement. Тут речь идет о нагрузке процессора, или, если по-другому настроить памяти) NB у меня в этой секции ## секция RUNTIME STATISTICS включено только (но именно включено)
stats_start_collector = true
stats_command_string = true
stats_row_level = true
Насколько я понимаю, запросы тоже достались по наследству и требуют оптимизации?
- Как часто делается VACCUUM FULL ANALIZE ?
- посмотрела еще раз на top повнимательней. Хочется увидеть конфиг - дается ли постгресу "развернуться" - по топу судя он мало ресурсов занимает, такое возможно при дефолном конфиге, но не эффективно. Надо выделить достаточное количество ресурсов и для кеширования, и для оптимизации запросов.
Соответственно секция RESOURCE USAGE (shared_buffers, work_mem, sort_mem), секция QUERY TUNING (особенно effective_cache_size)
NB - если что-то меняется в количестве заявленных буферов, памяти и т.д., то надо обязательно проверять, разрешено ли подобное в ядре, и если нет, менять соответствующим образом. см http://www.postgresql.org/docs/8.0/interactive/kernel-resources.html (там описано и для FreeBSD)
- по локам - max_locks_per_transactions и см. http://www.postgresql.org/docs/8.0/interactive/runtime-config.html#RUNTIME-CONFIG-LOCKS
- по числу процессов. Если мне не изменяет память, играет роль еще и порожденные процессы апача - в основном надо смотреть MaxRequestedPerChild (но на всякий случай и остальное из этой секции) - httpd.conf
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: neko
по поводу semwait
откуда такая уверенность что это не locks?
Нажмите для раскрытия...
Всё просто: когда дело в блокировках, он пишет "waiting".

Я тут сделал поиск по поводу PostgreSQL + Xeon:
http://archives.postgresql.org/pgsql-performance/2005-05/msg00441.php
http://archives.postgresql.org/pgsql-performance/2004-04/msg00249.php
http://dcs.nac.uci.edu/support/sysadmin/security/archive/msg01260.html
The original release of rh-postgresql did not have assembly-code spinlock
support for AMD64 and Intel EM64T architectures. Instead it used kernel
semaphore calls, which are far slower. Also, the number of semaphores
needed might exceed what the kernel is configured to allow, resulting in
database startup failure.
Нажмите для раскрытия...
Так что рекомендуется всё же попробовать upgrade до версии 8.1
 

mar

Новичок
кстати, про semwait - что дает
sysctl -a | grep sem
?
Если pg_dump живет в "periodic.conf или 502.pgsql " - так там и подправить, или вообще зашарить его там и прописать в crontab, а с ними разбираться на досуге, когда все остальное поборется .
ну и ждем конфига :)
 
Войдите или зарегистрируйтесь для ответа.
Сверху