2684 2003-06-20 01:11:07 +0400 Увеличить количество файлдескрипторов 2004-08-17 10:21:40 +0400 1 1 4 Development Sisyphus squid unstable all Linux CLOSED FIXED P4 normal --- 1 master kt egori shaba oldest_to_newest 2449 0 master 2003-06-20 01:11:07 +0400 В имеющейся сборке их 1024. Надо минимум 4096. Рыть в направлении $SQUID_MAXFD, $FD_SETSIZE и src/squid.h Даже в окружении пользователя с чрезмерными ulimits и выставленным sysctl, собирается только 1024. Чесно предупреждает об этом, при %configure. Ядро 2.4.21 Правка /usr/include/linux/limits.h тоже не помогла. --- --- Проверить можно с помощью cachemgr.cgi, запустив демона под ulimit -HSn 12227 1 master 2004-03-11 20:01:20 +0300 Есть рабочее/проверенное решение: http://devel.squid-cache.org/hno/linux-lfd.html более подробно: http://www.squid-cache.org/mail-archive/squid-users/200111/0471.html Запрос на правку glibc-devel я уже оформил в #3821 12281 2 pilot 2004-03-16 19:34:44 +0300 Рассказываю, что получилось у меня. После исследования glibc-devel и squid я понял, что FD_SETSIZE роли почти что и не играет, особенно если процесс сам в курсе о rlimits и т.п. В результате остаётся только обмануть configure/automake, так как squid не будет подниматься выше SQUID_MAXFD независимо от лимитов. Я проверил результат на своём контрибе и получилось! 2004/03/16 17:52:12| With 8192 file descriptors available Реально такое количество fd не тестировалось, пока негде. По наличию результатов будет пост на http://pilot.org.ua/ALT/#squid 1. Изменения в спек: +%__subst 's/^#define SQUID_MAXFD 1024/#define SQUID_MAXFD 8192/' include/autoconf.h %make_build 2. Изменения в squid.init: + ulimit -n 8192 daemon $SQUID $SQUID_OPTS 12289 3 master 2004-03-17 16:50:02 +0300 1. изменение в спек полностью поддерживаю 2. в squid.init у меня тоже именно так PS по поводу тестирования с 8192 дескрипторами, стало меньше тормозов, да и вообще - полет нормальный. my general runtime: Start Time: Thu, 11 Mar 2004 16:09:36 GMT Current Time: Wed, 17 Mar 2004 13:43:27 GMT Connection information for squid: Number of clients accessing cache: 139 Number of HTTP requests received: 9270549 Average HTTP requests per minute since start: 1091.4 Cache information for squid: Request Hit Ratios: 5min: 28.6%, 60min: 29.2% Byte Hit Ratios: 5min: 19.4%, 60min: 14.2% Request Memory Hit Ratios: 5min: 7.0%, 60min: 8.5% Request Disk Hit Ratios: 5min: 39.2%, 60min: 34.2% Storage Swap size: 7557112 KB Storage Mem size: 98292 KB Resource usage for squid: UP Time: 509630.769 seconds CPU Time: 85896.150 seconds CPU Usage: 16.85% CPU Usage, 5 minute avg: 48.44% File descriptor usage for squid: Maximum number of file descriptors: 8192 Largest file desc currently in use: 711 Number of file desc currently in use: 689 Available number of file descriptors: 7503 Reserved number of file descriptors: 100 Internal Data Structures: 643019 StoreEntries 19811 StoreEntries with MemObjects 19678 Hot Object Cache Items 642117 on-disk objects 12294 4 pilot 2004-03-17 22:18:44 +0300 Это по какому методу? 12321 5 master 2004-03-18 16:14:30 +0300 Это по "грязному" методу с хаком glibc http://devel.squid-cache.org/hno/linux-lfd.html Ваш способ с правкой спека я не проверял, т.к. у меня нормально работает сейчас моя сборка. За последних пару дней были ситуации, когда канал пропадал до 10 минут, а запросы от клиентов продолжались. В эти моменты сквид ставил запросы в очередь, при этом количество используемых дескрипторов возрастало до трех тысяч. После возобновления работы канала, все эти запросы были обработаны и сквид честно расслабился до 600 дескрипторов. В логах при этом никакой ругани небыло. То-есть все работает именно так, как и требовалось. 12323 6 pilot 2004-03-18 16:43:03 +0300 Тогда нужно проверить правильный метод, ведь обсудили, что FD_SETSIZE трогать нельзя. 13882 7 pilot 2004-05-17 14:31:02 +0400 Правильный метод работает, проверено временем. Давайте внедрять? 14880 8 master 2004-06-08 14:27:15 +0400 Ура, товарищи.