Re: Прокомментируйте пожалуйста
Прошу прощения за задержку - отдыхал. Ситуация следующая: 2004/09/07 06:52:14| 4390912 entries written so far. 2004/09/07 06:52:15| Finished. Wrote 4450672 entries. 2004/09/07 06:52:15| Took 66.9 seconds (66560.1 entries/sec). 2004/09/07 06:52:15| logfileRotate: /var/log/squid/access.log 2004/09/07 06:52:15| helperOpenServers: Starting 3 'squid_auth_sql' processes 2004/09/07 06:52:15| ipcCreate: fork: (12) Cannot allocate memory 2004/09/07 06:52:15| WARNING: Cannot run '/usr/lib/squid/squid_auth_sql' process. [...] Это происходит, когда делается rotate логов Squid. В это время обычно прыгает загрузка проца (ну и память наверное грузится). Причем swap до конца не используется... или он его освобождает ? Эти данные я вижу утром. Утром прокси перезапускается без проблем и работает до следующего logrotate. Mem: 1036928k total, 1010812k used,26116k free,50512k buffers Swap: 248968k total,48544k used, 200424k free, 298944k cached Я не большой спец в squid'е и не знаю в деталях что там происходит во время ротации логов, потому вопрос из общих соображений: ulimit/pam_limits не используются? Т.е. нет ли каких ограниченией на объёмы памяти, используемой приложением? Да, во время logrotate отрабатывает sarg. Файл access.log за день получается на 70 Мб. На самосборном 2.4.26 такой проблемы небыло. Может подскажите где прочитать про тюнинг 2.6 при помощи sysctl ? А то в гугле не нашел. И заодно идеи, что нужно подкрутить. В том-то и дело, что на мой взгляд, версия ядра к данной проблеме имеет косвенное отношение. Что ли скупое отношение ядра 2.6 к памяти не может так сказываться на squid'е.
Re: Прокомментируйте пожалуйста
Прошу прощения за задержку - отдыхал. Ничего, проблема решилась самым некрасивым путем, в сервер было вкинуто еще гиг памяти, это помогло. Кроме того был отключен sarge при ротации логов. Я не большой спец в squid'е и не знаю в деталях что там происходит во время ротации логов, потому вопрос из общих соображений: ulimit/pam_limits не используются? Т.е. нет ли каких ограниченией на объёмы памяти, используемой приложением? Нет. В том-то и дело, что на мой взгляд, версия ядра к данной проблеме имеет косвенное отношение. Что ли скупое отношение ядра 2.6 к памяти не может так сказываться на squid'е. Но кроме ядра ничего не менялось (из принципиальных вещей).
Re: Прокомментируйте пожалуйста
Спасибо, что ответили, помоему я наступил на эти грабли, насчет swap. Одна из особенностей 2.6 состоит в том, что оно неохотно использует swap, в отличии от 2.4, которое использует его более активно в угоду дисковым кешам - поэтому и page faults возникает чаще. Ситуация следующая: 2004/09/07 06:52:14| 4390912 entries written so far. 2004/09/07 06:52:15| Finished. Wrote 4450672 entries. 2004/09/07 06:52:15| Took 66.9 seconds (66560.1 entries/sec). 2004/09/07 06:52:15| logfileRotate: /var/log/squid/access.log 2004/09/07 06:52:15| helperOpenServers: Starting 3 'squid_auth_sql' processes 2004/09/07 06:52:15| ipcCreate: fork: (12) Cannot allocate memory 2004/09/07 06:52:15| WARNING: Cannot run '/usr/lib/squid/squid_auth_sql' process. 2004/09/07 06:52:15| ipcCreate: fork: (12) Cannot allocate memory 2004/09/07 06:52:15| WARNING: Cannot run '/usr/lib/squid/squid_auth_sql' process. 2004/09/07 06:52:15| ipcCreate: fork: (12) Cannot allocate memory 2004/09/07 06:52:15| WARNING: Cannot run '/usr/lib/squid/squid_auth_sql' process. 2004/09/07 06:52:31| aclMatchExternal: 'sql_auth' queue overload. Request rejected. 2004/09/07 06:52:35| aclMatchExternal: 'sql_auth' queue overload. Request rejected. 2004/09/07 06:52:36| aclMatchExternal: 'sql_auth' queue overload. Request rejected. 2004/09/07 06:52:36| aclMatchExternal: 'sql_auth' queue overload. Request rejected. 2004/09/07 06:52:39| aclMatchExternal: 'sql_auth' queue overload. Request rejected. 2004/09/07 06:52:41| aclMatchExternal: 'sql_auth' queue overload. Request rejected. Это происходит, когда делается rotate логов Squid. В это время обычно прыгает загрузка проца (ну и память наверное грузится). Причем swap до конца не используется... или он его освобождает ? Эти данные я вижу утром. Утром прокси перезапускается без проблем и работает до следующего logrotate. Mem: 1036928k total, 1010812k used,26116k free,50512k buffers Swap: 248968k total,48544k used, 200424k free, 298944k cached Да, во время logrotate отрабатывает sarg. Файл access.log за день получается на 70 Мб. На самосборном 2.4.26 такой проблемы небыло. Может подскажите где прочитать про тюнинг 2.6 при помощи sysctl ? А то в гугле не нашел. И заодно идеи, что нужно подкрутить.
Re: Прокомментируйте пожалуйста
Dmitriy Sirant wrote: Надоело каждый раз после выхода нового ядра собирать его с помощью kpackage, тем более, что по сути делался пакет, из которого выкидывалось ненужное (звук, видео, i2c, etc) а больше ничего существенного не менялось. Решил, что ядра которые идут в дистрибутиве - меня устроят Во-во. Смысл какой выкидывать ненужное? Неужели ради 20MB дополнительного свободного места в /lib/modules? Мне уже не раз приходилось сталкиваться с ситуациями когда к машине с таким вот облупленным ядром вдруг возникала необходимость подключить мобильник через usb/bluetooth или неподдерживаемую им сетевуху. В общем, глупость это. вполне. Ставлю kernel-image-2.4.27-1-686-smp, и замечаю, что жесткий диск IDE работает со скоростью 4 Мб/сек. Смотрю hdparm -i /dev/hda и вижу, что стоит udma5 (это то-же что и DMA=on ?). Пробую править /etc/hdparm.conf на предмет использования DMA, multisector но после перезагрузки эффект тот-же. Режим DMA обеспечиваются не столько hdparm'ом, сколько драйвером IDE-чипсета. Соответствующий модуль загружен? Number of HTTP requests received: 42470 Number of ICP messages received: 920 Page faults with physical i/o: 6 С ядром 4.26 и менее, Page faults был порядка 1000 при таком количистве запросов.С чем это связано ? Ядро настолько лучше работает ? Одна из особенностей 2.6 состоит в том, что оно неохотно использует swap, в отличии от 2.4, которое использует его более активно в угоду дисковым кешам - поэтому и page faults возникает чаще. octavia:~# w 19:22:58 up 2:15, 1 user, load average: 0.15, 0.19, 0.18 Эти значения load average это много или мало ? Как узнать насколько Мало. По этим значениям можно сказать, что вычичлительных и дисковых мощностей вполне достаточно. Кстати, google даёт хорошее ссылки на описание что такое load average. сильно загружен комп, какие системы (I/O, RAM, CPU) загружены больше всего ? vmstat - очень полезная утилита для начала. Есть подозрение, что компьютер слабоват, точнее, что много всего он делает: [...] И вполне справляется. -- Little known fact about Middle Earth: The Hobbits had a very sophisticated computer network! It was a Tolkien Ring...
Re: Прокомментируйте пожалуйста
В сообщении от 2 Сентябрь 2004 23:44 Dmitriy Sirant написал(a): Добрый день Вот рискнул сегодня на машинку (боевую) водрузить ядро 2.6. Хочу описать причину приведшую к этому, а Вы, если не сложно прокомментируйте, где неправильные предпосылки и возможно почему таковой результат. Итак. Машинка 2хPIII 1000, 1Gb RAM, 3xSCSI (Squid и MySQL), 80Gb IDE - все остальное. ну довольно не плохая машина:) Number of HTTP requests received: 42470 Number of ICP messages received: 920 Page faults with physical i/o: 6 С ядром 4.26 и менее, Page faults был порядка 1000 при таком количистве запросов.С чем это связано ? Ядро настолько лучше работает ? octavia:~# w 19:22:58 up 2:15, 1 user, load average: 0.15, 0.19, 0.18 Эти значения load average это много или мало ? Как узнать насколько сильно загружен комп, какие системы (I/O, RAM, CPU) загружены больше всего ? посмотри /var/log/sysstat/* если нету такого apt-get install sysstat Есть подозрение, что компьютер слабоват, точнее, что много всего он делает: Sendmail + Spamassasin + Clamav + POP3 + IMAP4 (~700 пользователей, 10 сообщений/мин) Squid + Transparent + Авторизация через MySQL ( 420 запросов/мин) Quagga (BGP) (можно и не обращать внимания собственно) Radius (Свои модули авторизации через MySQL) (~20 запросов/мин) Своя считалка траффика + запись его в MySQL Apache (порядка 30 хостов) Mysql 2.4.20 (~60 запросов/мин) Nagios проверяет живые хосты или нет Вот, что скажете, если где сделал неправильно - подскажите. на первый взгляд машинки более чем достаточно для такого -- С уважением, Юркин Евгений Siberia Health Inc
