SQUID съедает всю память
Здравствуйте!
(Сразу предупрежу, что пост большой, но пытался отобразить все свои предпринятые действия по устранению проблемы, а также наблюдения.)
Имею уже полгода проблему со Squid 3.1.* (до определённого момента всё было очень даже стабильно).
Squid после запуска растёт и растёт и растёт, пока не съест оперативную память и swap...
Наблюдать данное начал на старом сервере:
Linux gserver 2.6.27-gentoo-r8 #10 i686 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel GNU/Linux
На борту 2 Gb оперативной памяти.
Сначала думал что может неправильно сконфигурировал сквид, но даже поставив "минимальный" конфиг, без всяких в нагрузку acl, delay_pools, авторизации и т.д. squid всё равно съедает постепенно ВСЮ память!
Ладно, стал грешить на кривые руки и неправильно собранную ОС.
Взял новый системник, накатил туда свежую ОС Gentoo, uname -a:
Linux proxy.ircoc.vrn.ru 2.6.34-gentoo-r6 #3 x86_64 Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz GenuineIntel GNU/Linux
На борту 4 Gb оперативной памяти.
Поставил свежий Squid 3.1.8. Какое то время работало всё отлично, с авторизацией ntlm, бассейнами, списками доступа и т.д.
Часть юзеров висело на старом сервере, часть на новом (в общей сложности на двух серверах 122 юзера)
Но вот пришло время и в !ОДИН ДЕНЬ! и на старом сервере и на новом !ОДНОВРЕМЕННО! squid начал пожирать память как ему вздумается, и никогда её не высвобождать.
Ладно, начал пересобирать squid, использовал только (поминимуму) флаги (epoll ldap pam ssl). Поставил опять минимальный конфиг (не ругайте за такой адрес локальной сети, это до меня, пока не переделал):
proxy ~ # grep -v "^#" /etc/squid/squid.conf | sed -e '/^$/d' acl manager proto cache_object acl localhost src 127.0.0.1/32 192.92.92.100 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 acl localnet src 192.92.92.0/24 acl SSL_ports port 443 5222 5223 15100 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl Safe_ports port 901 # SWAT acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localnet http_access allow localhost http_access allow localhost http_access deny all http_port 192.92.92.100:3128 hierarchy_stoplist cgi-bin ? coredump_dir /var/cache/squid refresh_pattern ^ftp: &n... 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
Всё равно ест и ест память... И с cache_mem уже экспериментировал, и memory_pools выключал включал, и cache_dir отключал... Вобще не пойму в чём дело! Остальные программы на данном сервере крутятся круглосуточно без проблем...
Встречал похожую проблему здесь, решения там не оказалось:
http://opennet.ru/openforum/vsluhforumID12/3850.html?n=Андрей Слободяник
А также: http://www.gentoo.ru/content/pomogite-napisat-skript
Приведу наблюдения за памятью, очень странные, посмотрите, пожалуйста:
Старт сквида с нужным конфигом (acl, delay_pools, ntlm, cache_dir 10000, cache_mem 128 (аналогичные результаты и на 64, 256, 512 cache_mem)
2010-11-11 15:01:01 306760 KB
2010-11-11 16:01:01 1353816 KB
2010-11-11 17:01:01 1408724 KB
2010-11-11 18:01:01 2448968 KB
2010-11-11 19:01:01 2448968 KB
2010-11-11 20:01:01 2448968 KB
Здесь видно что процесс перестал расти в промежутке с 17 до 18 часов, хотя пользователей стало меньше ненамного с 50 до 30 штук.
Далее всю ночь процесс занимает 2448968 KB ни туда ни сюда (около 10 пользователей онлайн).
Настало утро, понеслось...
2010-11-12 9:45:01 2448968 KB
2010-11-12 9:46:01 2448968 KB
2010-11-12 9:47:01 2448968 KB
2010-11-12 9:48:01 2742476 KB
2010-11-12 9:49:01 3194164 KB
2010-11-12 9:50:01 3216340 KB
2010-11-12 9:51:01 3216340 KB
2010-11-12 9:52:01 3217192 KB
2010-11-12 9:53:01 3217532 KB
2010-11-12 9:54:01 3219148 KB
2010-11-12 9:55:01 3219856 KB
2010-11-12 9:56:01 3220300 KB
2010-11-12 9:57:01 3220700 KB
2010-11-12 9:58:01 3220880 KB
2010-11-12 9:59:01 3221456 KB
Всю ночь держался, а тут за 12 минут съел 700 мегабайт!!!! Пользователей на тот момент онлайн 30...
В конце концов:
2010-11-12 12:50:01 3495664 KB
Он залезает в swap и начинаются тормоза.
Хорошо, это был конфиг мной сооружённый.
Сделаем сквиду минимальный конфиг, его я приводил выше, наблюдаем за памятью:
Старт сквида
2010-11-12 15:53:01 46576 KB
Через час уже:
2010-11-12 17:02:01 1799352 KB
И растёт растёт растёт...
SQUID находится за IPTABLES, доступ извне запрещён.
Компов с заразой в сети вроде нет, траф wireshark смотрел - ничего подозрительного.
squid -k rotate делается каждые сутки.
Кеш сквида чистил миллион раз - не в нём дело.
Также пробовал и ограничивать memory_pools, например:
memory_pools on
memory_pools_limit 1970 MB
Не помогает...
GNUmalloc пробовал, результата 0.
Я уже и убунту (изначально всё на "собственно собранных" Gentoo держу, всё великолепно от домена, шлюза ... до БД) ставил, с её автоматическим установщиком и установкой самого сквида из репозиториев, с настройкой его по минимуму и всё равно сжирает память! И железо полностью менял. Причём ему пофиг 2 или 1 гигабайт ОЗУ, он их съедает как то почему то за одно и тоже время... Что делаю не так - без понятия. Тонны мануалов прочёл, по всем параметрам конфига ориентируюсь вполне уверенно.
Был бы очень признателен, если бы человек знающий или который держит сервер со сквидом на добрую сотню человек и не имеет с ним проблем, помог хотя бы небольшим советом.
P.S. А ещё интересует факт о том что сквид (с одинаковыми конфигами) под убунту кушает память неспеша и продолжительно, а на gentoo скачкообразно немереными порциями...
Пожалуйста, помогите решить проблему, замучился...
- Для комментирования войдите или зарегистрируйтесь
Покажите вывод "squidclient
Покажите вывод "squidclient mgr:info".
Squid mgr:info
Сейчас он только растёт, могу дать mgr:info в пик, когда начинает есть swap
Текущий конфиг:
Итого:
Number of clients accessing cache: 34
cache_mem 64 MB
memory_pools off
cache_dir ufs /mnt/cache/squid1g 1024 16 256
И куда ему столько памяти......:
Process Data Segment Size via sbrk(): 498404 KB
Вот это очень интересно:
Memory accounted for:
Total accounted: 84257 KB 17%
memPool accounted: 84257 KB 17%
memPool unaccounted: 414910 KB 83% !!!!!!!!!!!!!!!!!!!!!!!!!!
Цитата: Поставил свежий Squid
Может стоит откатиться?
Например на 2.7? Фирма долго
Например на 2.7?
Фирма долго не позволяет эксперементировать....
Зачем же так далеко. Если у
Зачем же так далеко. Если у вас версия 3.1.8 работала хорошо, на неё и откатиться. Кстати, в портежах эта версия помечена как стабильная.
Все 3.1.* так себя ведут в
Проблема в том, что сейчас все 3.1.* так себя ведут в моём случае...
Вот вобще жара: Process Data
Вот вобще жара: Process Data Segment Size via sbrk(): 2770756 KB
Вот эти два параметра:
Вот эти два параметра: "memPoolAlloc calls" и "memPoolFree calls" явно указывают, что Ваш Squid работает с памятью неправильно. Остальное было написано выше.
Согласен что неправильно... А
Не совсем согласен, такие показатели всегда при параметре memory_pools off как и в данном случае. Если memory_pools on то у меня эти показатели практически равны.
И о чудо! Откатился на Squid 2.7 Stable 7 - 100 клиентов, процесс весит 20 мегабайт, полёт нормальный!
Аналогичная проблема
Т.е. решается только откатом на ветку 2.7?
Справедливость восторжествует.
К сожалению.... Да... Я не
К сожалению.... Да... Я не знаю с чем это связано. И на убунте и на Gentoo сквид 3.1.* сжирает память. НУ ПРОСТО НЕ МОГУ НЕ ОТМЕТИТЬ! В Gentoo сквид кушает сразу порциями в сотню метров, в убунту потихонечку по парочке мегабайт!!! Ну как так?!
А вот 2.7 stable 9 живёт отлично стабильно с (таким же конфигом как в 3.1.* естественно под формат точил) авторизациями, ACLями, бассейнами, кэшем на 20гб и вобще делай что хочешь в конфиге, всё нормально.
Я не смог выяснить причину. Бился полгода.
И, да. Какое нервосбережение - просыпаться утром не думая о том, что из всего богатого арсенала серверов, должна умереть прокся...
А я то наивный, то патчи юзал то снижался в ветке 3.1, то на другую ОС ставил...
Хочу от себя ещё вот что сказать, переполнение зависит от некоторых клиентов сквида, так как в отпуске сидело человек 20 и всё было хорошо, как кто то появляется, то 3.1.* начинает падать
Jonny_Quest написал(а): К
И, я вас умоляю, дело не в конфиге
Столкнулся с аналогичным
Обнаружил аналогичное поведение squid 3.1.x. Удалось установить кто виноват, но по прежнему непонятно, что делать. Достаточно на яндекс через браузер попытаться отправить большой файл, как squid начнет жрать память. При 1 гиге физической памяти на сервере, squid может нормально прожевать файл до 500 мег. Если больше, то вся система летит в своп и наступают тупняки.
Эффект на 100% воспроизводимый.
top - 02:28:23 up 14 days, 13:50, 1 user, load average: 5.85, 4.92, 3.53
Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.2%us, 9.2%sy, 0.0%ni, 0.0%id, 86.5%wa, 0.8%hi, 0.3%si, 0.0%st
Mem: 1018452k total, 1004596k used, 13856k free, 1084k buffers
Swap: 8040524k total, 1005060k used, 7035464k free, 9384k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
163 root 10 -5 0 0 0 D 9.3 0.0 3:59.78 kswapd0
12433 squid 18 0 1057m 892m 2456 D 2.2 89.8 3:27.15 squid
RTFM! Настройте макс. размер
RTFM!
Настройте макс. размер кэшируемых файлов и все!
Хе! cache_mem 200
Хе!
cache_mem 200 mb
maximum_object_size 50 mb
Еще версии?
Version 3.1.10 of
Version 3.1.10 of Squid
Changes: This release brings a long list of bug fixes and some further HTTP/1.1 improvements. Some small but cumulative memory leaks were found and fixed in Digest authentication and adaptation ACL processing. New limits are placed on memory consumption when uploading files and when using delay pools. Users of Squid-3 experiencing memory or large cache problems are urged to upgrade as soon as possible.
Решено
Спасибо.
Убил пару часов на поиски нормального пакета под свою систему (centos 5.6), нашел:
squid-3.1.12-1.el5.src.rpm на сайте http://www.jur-linux.com/rpms/el-updates/5Client/SRPMS/ , он после установки нескольких библиотек нормально собрался в RPM. После апгрейда, баг изчез, теперь большие файлы нормально отдаются.