www.HardBlog.Net

FreeBSDКто нибудь сталкивался с

· 16 комментариев · Nix
GD Star Rating
loading...

FreeBSD

Кто нибудь сталкивался с подобной проблемой? Буду признателен любой помощи.

Спасибо.

ещё ?

Ruwiki_result_contestationПрошу прощения за вопрос не совсем по теме блог, но у меня сейчас доступ в интернет только с телефона, а кто-нибудь из вас наверняка сталкивался с чем-нибудь похожим. 77ed276c97920569b4f8f9c0b0ace452а кто нибудь сталкивался с этим чудом инженерной мысли? Кто-нибудь сталкивался с 63e921de5860Может кто-то сталкивался?
Tagged with →  

16 Responses to FreeBSDКто нибудь сталкивался с

  1. Yb_mo:
    Август 18, 2012 в 11:07

    Подземный стук, а не описание проблемы. Посотри slow log в mysql что ли.

    Ответить
  2. Namwhite:
    Август 18, 2012 в 12:00

    : Смотрел. Индексы везде где можно включили, но на InnoDB перейти возможности нет. Да и во время перезапуска апача количество коннектов к мусклю не превышает 20-30 штук, что для такой машины вообще не нагрузка. Да и взлетающий до небес system говорит что проблема в чем-то другом. Если бы в мускле – влетал бы скорее всего user.

    Ответить
  3. Oziam:
    Август 18, 2012 в 12:09

    ну хоть top -S что выдает?

    Ответить
  4. Namwhite:
    Август 18, 2012 в 12:17

    : вот 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

    Ответить
  5. SamRain:
    Август 18, 2012 в 12:50

    А почему так много cgi запущено? это нормально? не апач ли при перезапуске их плодит и они дружно пытаются дергать БД и стопорят систему? Да и количество процессов впечатляет.

    Ответить
  6. Namwhite:
    Август 18, 2012 в 13:30

    : это те самые скрипты от которых нельзя отказаться пока. 🙁

    Ответить
  7. Namwhite:
    Август 18, 2012 в 13:32

    : да и как я писал уже выше – количество коннектов к мусклю ничтожно мало

    Ответить
  8. Yb_mo:
    Август 18, 2012 в 13:33

    : Ну вот и ответ.

    Ответить
  9. Namwhite:
    Август 18, 2012 в 13:41

    : и нет никаких вариантов без замены скриптов? почему может system то расти так что только рестарт мускля помогает?

    Ответить
  10. Yb_mo:
    Август 18, 2012 в 13:53

    : Эти скрипты дергают mysql? Если да – то это и ответ.

    Ответить
  11. Namwhite:
    Август 18, 2012 в 13:58

    : может можно както затюнить мускуль? свободной памяти то дофига. могу приложить текущий конфиг мускля.

    Ответить
  12. Yb_mo:
    Август 18, 2012 в 14:03

    http://gert.sos.be/en/projects/mysqlar/ попробуй вот этой штукой собрать статистику и посмотреть результат.

    Ответить
  13. Namwhite:
    Август 18, 2012 в 14:11

    : я вот этой штукой тюнил http://mysqltuner.pl/mysqltuner.pl и есть мунин. но на нем нет ничего военного. 🙁

    попробую еще твою ссылку, отпишу о результатах, спасибо.

    Ответить
  14. SamRain:
    Август 18, 2012 в 14:40

    : Ну на это тоже могут быть причины. Во время начинания тормозов советую выполнить запрос

    SHOW PROCESSLIST

    И посмотреть что к чему. Ну и разобраться с процессами само собой чтобы на старте вели себя нормально.

    Ответить
  15. AliAll:
    Август 24, 2012 в 04:46

    iostat 2
    что-нибудь интересное выдает?

    Ответить
  16. Namwhite:
    Август 24, 2012 в 06:30

    : проблема была относительно решена. оказалось что такое поведение при graceful перезапуске апача. если убивать полностью и пускать заново – такой проблемы нет.

    Ответить

Добавить комментарий