используется Fedora 5
стоит Apache порядка 10 виртуал хостов
в некоторое время сервер стал жутко тормозить
LA 15-20
Стал разбираться что тормозит, определил основных кандидатов
Apache, Sendmail, Mysql
написал демона который раз в минуту чекает процессы и записывает и ttime
также чекает LA

Построил графики sum(ttime) от hour(time) и avg(LA) от hour(time) - они совершенно разные,
топ avg(LA) описывает реальную картинку, LA максимально в пик загрузки сервера, а пик sum(ttime) попадает на ночь, при этом днем все ништяк.
Решил оптимизировать все.
Дал больше памяти mysql, поставил nginx фронтендом к апач
Все равно жуткие тормоза.

Решил что это все же Apache, написал скрипт воссоздания нагрузки.
Он берет инфу из лога nginx и в 20 процессов с локалхоста грузит эти urlы.
Запустил его ночью
При этом LA вырос до таких же значений что и в пик днем, но при это сайты грузились нормально, службы работали, в то время как днем при таком же LA бвл просто ПЦ.

Как еще можно диагнозтировать - что же создает такой ПЦ, где я лажаю в своих рассуждениях.

• Как узнать что грузит сервер,smile, 16:44 , 17-Окт-08
  • Как узнать что грузит сервер,evger, 17:22 , 17-Окт-08
    • Как узнать что грузит сервер,evger, 17:32 , 17-Окт-08
• Как узнать что грузит сервер,evger, 14:33 , 20-Окт-08
• Как узнать что грузит сервер,evger, 19:38 , 20-Окт-08
  • Как узнать что грузит сервер,славик, 18:10 , 08-Фев-09
    • Как узнать что грузит сервер,evger, 18:39 , 08-Фев-09

>[оверквотинг удален]
>Решил что это все же Apache, написал скрипт воссоздания нагрузки.
>Он берет инфу из лога nginx и в 20 процессов с локалхоста
>грузит эти urlы.
>Запустил его ночью
>При этом LA вырос до таких же значений что и в пик
>днем, но при это сайты грузились нормально, службы работали, в то
>время как днем при таком же LA бвл просто ПЦ.
>
>Как еще можно диагнозтировать - что же создает такой ПЦ, где я
>лажаю в своих рассуждениях.

в момент пиковой загрузки попробуйте mytop'ом посмотреть - может особо зловонный запрос залочил собой какую-нить таблицу и его собратья стоят за ним в очереди? а причин к описанным симптомам может быть очень много, в частности - ошибки релизации работы с кешем при одновременном доступе...

>в момент пиковой загрузки попробуйте mytop'ом посмотреть - может особо зловонный запрос
>залочил собой какую-нить таблицу и его собратья стоят за ним в
>очереди?

а что я должен наблюдать? стандартная картина 10 висящих httpd, и пара perl скриптов, переодически скачет.
>а причин к описанным симптомам может быть очень много, в
>частности - ошибки релизации работы с кешем при одновременном доступе...

кэш имеется ввиду кэш apache и nginx? или кэш реализованный в движке сайтов?

у меня есть некоторые идеи которые я не знаю как проверить,
1) ограничение на количество сокетов, - может просто процессы стоят в ожидании свободного сокета
2) ограничение на колличество открытых файлов
3) какие-то ограничения mysql на число коннектов
Вот статы, может Вы что-то увидите
==================
mysqladmin status
Uptime: 60970  Threads: 2  Questions: 322707  Slow queries: 303  Opens: 637  Flush tables: 1  Open tables: 256  Queries per second avg: 5.293
====================
top - 17:19:58 up 1 day,  1:59,  1 user,  load average: 22.77, 26.79, 27.17
Tasks:  69 total,   1 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2% us,  1.5% sy,  0.0% ni, 34.0% id, 61.2% wa,  0.0% hi,  0.0% si,  0.0% st
Mem:   8235292k total,   197936k used,  8037356k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached
user apache
7968 apache    18   0  5064 3368 1548 D    2  0.0   0:00.09 index.cgi
26438 apache    15   0 96820  35m 8136 S    2  0.4   0:01.37 httpd
26210 apache    16   0 72956  15m 6040 S    0  0.2   0:02.60 httpd
5896 apache    17   0 69368   9m 1948 S    0  0.1   0:00.00 httpd
20348 apache    15   0 72980  17m 8504 S    0  0.2   0:01.14 httpd
20446 apache    16   0 72952  15m 5972 S    0  0.2   0:02.20 httpd
23600 apache    15   0 72968  15m 6000 S    0  0.2   0:01.24 httpd
23609 apache    15   0 72976  15m 5992 S    0  0.2   0:02.37 httpd
24392 apache    15   0 72968  17m 8140 S    0  0.2   0:02.27 httpd
24404 apache    15   0 72916  17m 8292 S    0  0.2   0:01.26 httpd
28656 apache    15   0 72972  17m 8200 S    0  0.2   0:01.38 httpd
user root
1624 root      16   0 39340  33m 2380 S    2  0.4   0:38.27 spamd
1858 root      15   0 37000  31m 2384 S    1  0.4   0:26.72 spamd
9320 root      21   5  8572 3796 2556 D    1  0.0   0:00.04 sendmail
6106 root      21   5  8696 3868 2616 D    1  0.0   0:00.08 sendmail
9288 root      20   5  8568 3796 2560 S    1  0.0   0:00.04 sendmail
5511 root      18   0  8116 2468  804 D    0  0.0   0:02.48 sendmail
5668 root      18   0  7500 1656  704 D    0  0.0   0:00.80 sendmail
5835 root      15   0  2060 1028  796 R    0  0.0   0:00.25 top
7520 root      21   5  8692 3860 2616 D    0  0.0   0:00.05 sendmail
7591 root      22   5  8688 3868 2620 D    0  0.0   0:00.05 sendmail
14260 root      18   0  7644 1916  804 D    0  0.0   0:07.07 sendmail
20127 root      17   0  7916 2172  804 D    0  0.0   0:14.12 sendmail
    1 root      15   0  1932  672  576 S    0  0.0   0:02.20 init
3544 root      18   0  8116 2476  804 D    0  0.0   0:04.49 sendmail
5518 root      18   0  8112 2464  804 D    0  0.0   0:02.66 sendmail
5753 root      21   5  8568 3788 2556 S    0  0.0   0:00.04 sendmail
6075 root      15   0  1584  564  472 S    0  0.0   0:33.88 syslogd
7214 root      18   0  4920 1116  796 S    0  0.0   0:00.01 sshd
7699 root      21   5  8692 3832 2584 D    0  0.0   0:00.05 sendmail
7755 root      15   0 31396  25m 2352 S    0  0.3   0:21.55 spamd
8033 root      15   0  5464 1124  572 S    0  0.0   0:00.20 crond
8059 root      18   0  6416  908  548 S    0  0.0   0:00.00 squid
8064 root      19   0  1936  488  380 S    0  0.0   0:00.00 ncsa_auth
8067 root      20   0  1928  484  380 S    0  0.0   0:00.00 ncsa_auth
8068 root      19   0  1932  488  380 S    0  0.0   0:00.00 ncsa_auth
8069 root      19   0  1932  484  380 S    0  0.0   0:00.00 ncsa_auth
8070 root      19   0  1932  488  380 S    0  0.0   0:00.00 ncsa_auth
8114 root      15   0  5168 1280  976 S    0  0.0   0:00.00 saslauthd
9297 root      21   5  8704 2440 1160 D    0  0.0   0:00.00 sendmail
9901 root      18   0  7504 1844  804 D    0  0.0   0:03.28 sendmail
19672 root      15   0  2152  844  700 S    0  0.0   0:00.93 xinetd
19820 root      18   0  4620 1284 1108 S    0  0.0   0:00.01 mysqld_safe
20174 root      15   0 69228  15m 7968 S    0  0.2   0:00.55 httpd
21658 root      21   5  8688 3804 2560 S    0  0.0   0:00.04 sendmail
24127 root      15   0  7928 2404 1944 S    0  0.0   0:00.07 sshd
25762 root      20   5  8700 3860 2604 S    0  0.0   0:00.06 sendmail
27912 root      18   0  4772 1524 1228 S    0  0.0   0:00.04 bash
27961 root      18   0  7068 1488  540 S    0  0.0   0:00.00 nginx
32371 root      21   5  8680 3860 2620 S    0  0.0   0:00.07 sendmail

netstat -s
Tcp:
    49996 active connections openings
    75719 passive connection openings
    787 failed connection attempts
    7917 connection resets received
    29 connections established
    2181883 segments received
    2146656 segments send out
    30663 segments retransmited
    9 bad segments received.
    21484 resets sent
нет ли тут чего нить подозрительного?

ответ кроется в wa 80-90%
как я понимаю это iowait, т.е куча процессов ждет завершение I/O операции.
вопрос как узнать - какие процессы, и почему не могут прочитать или записать.

проблема решена.

>проблема решена.

что же там было, и как решил?

>>проблема решена.
>
>что же там было, и как решил?

верхняя строчка top
61% WA
это Wait input output operation

разрослись почтовые ящики, при получении письма sendmail дописывал в огромные файлы жрал весь ресурс винта, из за этого вставали все процессы - ждали запись или чтение файла.