: Смотрел. Индексы везде где можно включили, но на InnoDB перейти возможности нет. Да и во время перезапуска апача количество коннектов к мусклю не превышает 20-30 штук, что для такой машины вообще не нагрузка. Да и взлетающий до небес system говорит что проблема в чем-то другом. Если бы в мускле – влетал бы скорее всего user.
А почему так много cgi запущено? это нормально? не апач ли при перезапуске их плодит и они дружно пытаются дергать БД и стопорят систему? Да и количество процессов впечатляет.
: проблема была относительно решена. оказалось что такое поведение при graceful перезапуске апача. если убивать полностью и пускать заново – такой проблемы нет.
Здесь говорят о компьютерах, ноутбуках, железе, серверах, операционных системах и прочем харде и софте. Всё, что вы найдёте здесь, вы можете полностью и свободно перепечатать и процитировать. Ссылка на http://www.hardblog.net не обязательна, но если вы её поставите, то будет здорово.
Подземный стук, а не описание проблемы. Посотри slow log в mysql что ли.
: Смотрел. Индексы везде где можно включили, но на InnoDB перейти возможности нет. Да и во время перезапуска апача количество коннектов к мусклю не превышает 20-30 штук, что для такой машины вообще не нагрузка. Да и взлетающий до небес system говорит что проблема в чем-то другом. Если бы в мускле – влетал бы скорее всего user.
ну хоть top -S что выдает?
: вот top -S после рестарта апача.
last pid: 41116; load averages: 15.24, 6.07, 4.62 up 7+00:13:05 11:11:13
667 processes: 72 running, 580 sleeping, 6 zombie, 1 waiting, 8 lock
CPU: 7.1% user, 0.0% nice, 83.6% system, 4.9% interrupt, 4.5% idle
Mem: 1486M Active, 13G Inact, 4813M Wired, 2832K Cache, 3283M Buf, 12G Free
Swap: 8192M Total, 1348K Used, 8191M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 16 155 ki31 0K 256K RUN 15 2092.8 188.23% idle
84549 mysql 67 23 0 6785M 1395M uwait 6 157:42 141.11% mysqld
12 root 33 -72 – 0K 528K WAIT 0 20.3H 77.44% intr
40866 ftp0 1 75 0 22612K 3700K RUN 1 0:02 12.06% cron.cgi
40868 ftp0 1 75 0 3548K 2152K RUN 7 0:02 11.87% cron.cgi
40907 ftp0 1 75 0 7588K 4616K RUN 8 0:01 11.57% cron.cgi
40140 root 1 26 0 20796K 4824K CPU12 12 0:03 10.69% top
41060 www 1 41 0 2476K 812K piperd 6 0:00 10.60% out.cgi
41084 www 1 52 0 2476K 812K RUN 9 0:00 10.50% out.cgi
41027 www 1 44 0 11400K 1200K piperd 8 0:00 10.25% out.cgi
41083 www 1 31 0 460K 192K CPU14 4 0:00 10.25% out.cgi
40104 www 1 32 0 333M 25500K RUN 13 0:02 9.67% httpd
40953 www 1 35 0 2476K 852K RUN 2 0:00 9.67% out.cgi
41007 www 1 36 0 2476K 860K RUN 14 0:00 9.57% out.cgi
40091 www 1 36 0 333M 22804K kqread 4 0:02 9.38% httpd
40116 www 1 52 0 333M 22760K accept 0 0:02 9.08% httpd
41031 www 1 44 0 0K 16K RUN 8 0:00 8.89% out.cgi
40117 www 1 40 0 333M 22324K kqread 13 0:01 8.50% httpd
40069 www 1 31 0 333M 22512K kqread 9 0:02 8.40% httpd
41029 www 1 39 0 18504K 2008K RUN 1 0:00 8.40% out.cgi
41081 www 1 74 0 12140K 1120K RUN 11 0:00 8.40% ltdltest
41055 www 1 52 0 2476K 812K piperd 2 0:00 8.25% out.cgi
41068 www 1 52 0 2436K 772K piperd 7 0:00 8.25% in.cgi
40062 www 1 38 0 333M 24012K kqread 4 0:02 8.06% httpd
40935 www 1 30 0 2460K 1160K *vm ob 15 0:00 8.06% in.cgi
40154 www 1 46 0 333M 22664K CPU1 0 0:01 7.96% httpd
41085 ftp0 1 74 0 460K 212K RUN 4 0:00 7.96% ltdltest
41078 www 1 52 0 2436K 772K piperd 2 0:00 7.86% in.cgi
40083 www 1 31 0 333M 23908K kqread 7 0:02 7.76% httpd
41015 www 1 37 0 18504K 1788K CPU10 10 0:00 7.67% out.cgi
41030 www 1 74 0 11400K 1252K RUN 14 0:00 7.67% out.cgi
40106 www 1 33 0 333M 24824K RUN 14 0:02 7.57% httpd
40108 www 1 28 0 333M 23088K sbwait 1 0:01 7.57% httpd
41881 www 1 20 -10 25276K 7104K kqread 10 29:35 7.37% nginx
А почему так много cgi запущено? это нормально? не апач ли при перезапуске их плодит и они дружно пытаются дергать БД и стопорят систему? Да и количество процессов впечатляет.
: это те самые скрипты от которых нельзя отказаться пока. 🙁
: да и как я писал уже выше – количество коннектов к мусклю ничтожно мало
: Ну вот и ответ.
: и нет никаких вариантов без замены скриптов? почему может system то расти так что только рестарт мускля помогает?
: Эти скрипты дергают mysql? Если да – то это и ответ.
: может можно както затюнить мускуль? свободной памяти то дофига. могу приложить текущий конфиг мускля.
: я вот этой штукой тюнилhttp://mysqltuner.pl/mysqltuner.pl и есть мунин. но на нем нет ничего военного. 🙁
попробую еще твою ссылку, отпишу о результатах, спасибо.
: Ну на это тоже могут быть причины. Во время начинания тормозов советую выполнить запрос
SHOW PROCESSLIST
И посмотреть что к чему. Ну и разобраться с процессами само собой чтобы на старте вели себя нормально.
iostat 2
что-нибудь интересное выдает?
: проблема была относительно решена. оказалось что такое поведение при graceful перезапуске апача. если убивать полностью и пускать заново – такой проблемы нет.