squid под высокой нагрузкой. [частично решено]

EXTRA_ECONF='foo-bla' emerge squid попробуйте

В ебилде

  --with-filedescriptors=8192 \

этого реально мало ? Ну не верю я :(
Но если так хочется :

--- /usr/portage/net-proxy/squid/squid-3.0.18-r1.ebuild 2009-08-31 03:12:30.000000000 +0300
+++ squid-3.0.18-r10.ebuild     2009-09-17 00:14:43.866830803 +0300
@@ -69,6 +69,9 @@
 }

 src_configure() {
+
+       : ${SQUID_FILEDESCPTOR:=8192}
+
        local basic_modules="getpwnam,NCSA,MSNT"
        use samba && basic_modules="SMB,multi-domain-NTLM,${basic_modules}"
        use ldap && basic_modules="LDAP,${basic_modules}"
@@ -129,7 +132,7 @@
                --enable-referer-log \
                --enable-arp-acl \
                --with-large-files \
-               --with-filedescriptors=8192 \
+               --with-filedescriptors=${SQUID_FILEDESCPTOR} \
                $(use_enable caps) \
                $(use_enable snmp) \
                $(use_enable ssl) \

Сильно не пинать, сделано "на коленке " за 10 минут

Стал копаться дальше.

Выяснилось опытным путём, что квота на файловые дескрипторы исчерпывалась из-за большого количества используемых ntlm-аутентификаторов. Внимательные наблюдения за mgr:ntlmauthenticator показали, что реально задействовано куда меньше их, чем указано в конфиге. Почему ж тогда их количество увеличивалось? Да потому что сквид в противном случае сильно ругался на их недостачу, а потом отваливался. Вот, сейчас, когда на сервере одновременно работает 110 клиентов и скорость запросов составляет 40 запр/сек, я для эксперимента уменьшил следующие значения:

auth_param ntlm children 25
auth_param basic children 5
external_acl_type acc_grp ttl=60 negative_ttl=60 children=15 %LOGIN /usr/libexec/squid/wbinfo_group.pl

Соответственно, эффект от этого не замедлил сказаться и виден постом выше. Жалобы на количество ФД пропали, но появилась опасность того, что снова будет эта непонятка с ntlm. Вот, какая нынче статистика даётся:

NTLM Authenticator Statistics:
program: /usr/bin/ntlm_auth
number active: 25 of 25 (0 shutting down)
requests sent: 35711
replies received: 35711
queue length: 0
avg service time: 0 msec

      #      FD     PID  # Requests      # Deferred Requests    Flags      Time  Offset Request
      1       8    3149        2390                        0      R       0.007       0 (none)
      2       9    3150         832                        0      R       0.000       0 (none)
      3      10    3151         493                        0      R       0.000       0 (none)
      4      11    3152        2802                        0      R       0.001       0 (none)
      5      12    3153        1247                        0      R       0.004       0 (none)
      6      13    3154         951                        0      R       0.001       0 (none)
      7      14    3155         377                        0      R       0.000       0 (none)
      8      15    3156         172                        0      R       0.002       0 (none)
      9      16    3157         170                        0      R       0.004       0 (none)
     10      17    3158          54                        0      R       0.002       0 (none)
     11      18    3159        2243                        0      R       0.001       0 (none)
     12      19    3160        3684                        0      R       0.062       0 (none)
     13      20    3161         494                        0      R       0.000       0 (none)
     14      21    3162        9007                        0      R       0.001       0 (none)
     15      22    3163        2935                        0      R       0.000       0 (none)
     16      23    3165         336                        0      R       0.007       0 (none)
     17      24    3166        4235                        0              0.007       0 (none)
     18      25    3167        1478                        0      R       0.002       0 (none)
     19      26    3168         916                        0              0.008       0 (none)
     20      27    3169         460                        0              0.007       0 (none)
     21      28    3170         227                        0              0.006       0 (none)
     22      29    3171          78                        0              0.017       0 (none)
     23      30    3172          42                        0              0.013       0 (none)
     24      31    3173          32                        0              0.009       0 (none)
     25      32    3174          56                        0              0.025       0 (none)

Flags key:

   B = BUSY
   C = CLOSING
   R = RESERVED or DEFERRED
   S = SHUTDOWN PENDING
   P = PLACEHOLDER

Вот эти вот хелперы с флагом R с 1 по 16 висят так довольно долго, т.о. реально работают только с 17 по 25 хелперы, которые тоже то блокируются, то разблокируются. И я думаю, что когда заблокируются эти оставшиеся, тут то сквид и зажалуется. С чем такое связано может быть? Есть подозрение, что с одним из таймаутов в секции TIMEOUTS

Рытьё интернетов показало, что эта бага с зависающими ntlm-аутентификаторами присуща squid-3.xx. Когда это понял, то решил в качестве последнего шага попробовать обновиться до 3.0.19 и оказалось, что там его исправили. Во всяком случае, зависаний ни в пятницу, ни в субботу замечено не было.

router ~ # less /etc/conf.d/squid
/* вжжжик - ААААА!!! */
# Max. number of filedescriptors to use. You can increase this on a busy
# cache to a maximum of (currently) 8192 filedescriptors. Default is 1024.
SQUID_MAXFD=1024
/* вжжжик - ААААА!!! */
Вот здесь еще подкрутить надо...
Я когда-то на эти грабли наступал. В ебилде действительно 8192, но надо прописывать и тут =)
Но в моем случае надо было не сквиду дескрипторы прибавлять, а прибить злобного трояна на юзерской машине, которому хозяин сказал делать DDoS какого-то там сайта по порту 80. DoS почти получился, но не того сервера, а моего прокси. Рекомендую поставить sqstat, если еще не стоит, и посмотреть в реальном времени, что с запросами творится (squid в access.log пишет только завершенные запросы!) Ну и в cache.log тоже бывают жалобы на неправильные запросы от такого-то ip...

соберите сквид с поддержкой epoll погоняйте с ним...
ядро тоже должно уметь работать с epoll

# zgrep EPOLL /proc/config.gz
CONFIG_EPOLL=y