select(3c) не поддерживает более чем 1024 файловых дескрипторов. Скрипт configure по умолчанию должен включить poll() для Solaris. poll() позволяет вам использовать больше файловых дескрипторов, 8192 или более.
Для старых версий Squid вы можете включить poll() вручную, изменив HAVE_POLL в файле include/autoconf.h или добавив -DUSE_POLL=1 к the DEFINES в src/Makefile.
В libmalloc.a есть утечка памяти. Squid-вый configure не использует -lmalloc на Solaris.
от David J N Begley.
Запросы DNS могут обрабатываться медленно из-за одной таинственной штуки, называемой ncsd. Вам придется отредактировать /etc/nscd.conf и указать следующее:
enable-cache hosts no
Очевидно nscd множит DNS запросы, что заставляет все тормозить, когда приложение (типа Squid) существенно нагружает резолвер. Вы можете заметить нечто подобное, если у вас вы запустили обработчик журнала выполняющий множество запросов к резолверу DNS, резолвер начинает притормаживать.. и умирает. . . .
Согласно сообщению Andres Kroonmaa, пользователи Solaris начиная с версии 2.6 и выще НЕ ДОЛЖНЫ полностью выключать демон nscd. Все же nscd должен быть запущен и кешировать файлы групп и паролей, хотя предлагается выключить кеширование хостов, т.к. это может привести в запросам DNS.
Некторые библиотечные вызовы полагаются на доступность свободных ФАЙЛОВЫХ дескрипторов FD < 256. Системы запущенные без nscd могут необратабывать подобные вызовы, если все из первых 256 дескрипторов заняты.
Начиная с Solaris 2.6 Sun изменил способ работы некоторых системных вызовов и используют демона nscd как их замену . Чтобы обращаться к nscd Solaris использует недокументированные вызовы. В основном nscd применяется, чтобы уменьшить кол-во используемой памяти в системных библиотеках user-space, которые работают с файлами passwd и group. До 2.6, Solaris полностью кешировал файл passwd в памяти при первом к нему обращении, но оказалось, что это требует слишком много ОЗУ на больших многопользовательских системах и Sun решил переместить выполнение этих вызовов из библиотек в одного выделенного демона.
от Jason Armistead.
Файл /etc/nsswitch.conf определяет и порядок обработки запросов DNS (среди прочих вещей). Ввозможно вы хотели бы указать, что разрешается обрабатывать только файлы NIS или HOSTS. Но вы определенно хотите указать строку "hosts:" и включить в нее слово dns, к примеру:
hosts: nis dns [NOTFOUND=return] files
by Chris Tilbury.
Наш кеш запущен на машине с Solaris 2.6. Мы используем NIS, чтобы распределять ацтентификацию и локкальную информацию о хостах по нашим много пользовательским системам, мы запустили вспомогательный сервер NIS на этойй машине, в помощь в обработке запросов NIS.
Мы наблюдали большой интервал времени обработки запроса имя->ip (в среднем ~2 сек.) и ip->имя (в среднем ~8 сек.), хотя казалось никакой проблемы со временем ответа не было для существующих сайтов, пока кеш на начинал работать под большой нагрузкой. Тогда вся производительность смываласьв унитаз.
Через некоторое время и некторое кол-во детективной работы, мы обнаружили проблему. На Solaris 2.6, если у вас есть локальный сервер NIS с запущенным (ypserv) и в файле /etc/nsswitch.conf указано NIS в записи hosts, то проверьте флаг, с которым он стартует. В 2.6 скрипт ypstart проверяет существует ли файл resolv.conf в момент запуска ypserv. Если он существует, то сервер стартует с флагом -d.
Тот же самый эффект будет, если указать ключ YP_INTERDOMAIN в таблице хостов, а именно неудачные звпросы хостов по NIS пытаются использовать DNS после сервера NIS.
Это bad thing(tm)! Если NIS самостоятельно пытается определить имена, используя DNS, то запросы будут множится через NIS-сервер, образуя эффект бутылочного горлышка (таже ввобщем проблема, что и с nscd). Т.е., один неудачный запрос может, если у вас указано NIS перед DNS файле переключения служб (в общем случает так оно и есть), задержит каждый следующий запрос, имеющий место.
Если у вы работаетет с подобным типом настроек, то вам необходимо будет убедиться, что
Мы поменяли вышеуказанное и заметили, что среднее время ответов упали на порядок (~150 msec для запросов имя->ip и ~1.5sec для запросов ip->имя, последний параметр вще еще достаточно велик, я предполагаю, что большинство из этих запросов завершились неудачно или достигли таймаута, т.к. они не делаются столь часто, да и подобные записи зачастую не существуют).
Solaris 2.x - tuning your TCP/IP stack and more by Jens-S. Vckler
Вы можете получить такое сообщение о ошибке, даже когда на самом деле ваш диск еще не заполнен и inodes тоже не закончились. Проверьте журнал вашего syslog (обычно располагается в /var/adm/messages) на придемет пподобных сообщений:
NOTICE: realloccg /proxy/cache: file system full
NOTICE: alloc: /proxy/cache: file system full
В двух словах - файловая система, используемая Solaris не может на должном уровне справиться рабочей нагрузкой, которую на нее возлагает Squid. Файловая ситстема будет становиться слишком фрагментированной, пока это не не длостигнет момента, когда не хватает свободных блоков для создания файлов, а доступны только фрагменте. В этот момент вы получите подобное сообщение о ошибке и squid пересмотрит данные о том, сколько свободного места ему фактически доступно. Вы можете запустить "fsck -n raw_device" (нет необходимости делать umount, проверка будет проходит в режиме read only), чтобы посмотреть на уровень фрагментации файловой системы. Он скорее всего будет достаточно высок (>15%).
Sun предлагает два решения этой проблемы. Одно из них стоит денег, второе - бесплатное, но его результатом может стать снижение производительности (хотя Sun утвердяет, что этого происходить не должно, даже если учыитывать слишком случайную природу доступа squid к диску).
Первое решение - купить копию VxFS, файловой системы Veritas. Это extent-based файловая система и производить дефрагментациюб "налету", которая выполняется на подмонтированной файловой системе. Однако это стоит денег (VxFS - совсем не дешево!).
Второе решение состоит в изменении определенных параметров файловой системы UFS. Отмонтируйте вашу файловую систему с кешем и используйте tunefs, чтобы изменить оптимизацию на "space" и уменьшить значение "minfree" до 3-5% (под Solaris 2.6 и более новых очень большие файловые системы почти всегда будут иметь значение minfree около 2% и вы не должны его увеличивать). Применяя этот способ вы должны снизить уровень фрагментации приблизительно до 3%, что будет сопровождатся увеличением доспупного места на диске.
Благодарность Chris Tilbury.
От Jeff Madison
Важное дополнение относительно Squid запущенного Solaris x86. Я работал в течение нескольких месяцев, чтобы разобраться тем, что казалось утечкой памяти в squid, который работал под Solaris x86, и не зависело от имппользуемой malloc. Я сделал два открытия, которые могут заминтересовать тех, кто использует Squid на этой платформе.
Во-первых: Нет никакой утечки памяти в Squid, когда система поработает некоторое кол-во времени, что зависит от нагрузки, под которой она находится, Top сообщает, что свободной памяти осталось очень немного. True to the claims of the Sun engineer я говорил, что эта статистика Top некорректна. Самая неприятная вещь, что действительно начинаете замечать, что производительность со временем падает и единственный выход исправить ситуацию - перегрузить систему. Это приводит меня ко второму открытию.
Во-вторых: Существуют несколько типов проблем с ресурсами, памятью или чем-то другим, при использовании IPFilter на Solaris x86. Я не тратил время, чтобы выяяснить, в чем собственно заключаются эти проблемы, т.к. мы больше не используем IPFilter. Мы переключились на коммутатор Alteon ACE 180 Gigabit, который поддерживает прозрачное проксирование. После переезда на trans-proxy, процесс перенаправления выполняет свитч Alteon, Squid работал 3 дня под большой нагрузкой без каких-либо проблем. Мы сейчас имеем две машины с 40 GB закешированных объектов на каждой. Эти 40 GB были заполнены за 3 дня, можете сами судить под какой нагрузкой работают эти две машины. До этих изменений мы никогда не были в состоянии проработать больше 4-х часов подряд.
Поскольоку проблема по всей видимости с IPFilter, я могу предположить, что вы с ней столкнетесь, если попытаетесь запустить Squid как прозрачный прокси при помощи IPFilter. Что имеет смысл. Если кто-либо располагает информацией о том, что мои догадки неверны, я продолжу свои изыскания вдальнейшем.
В Solaris переменная ядра для размера кеша поиска имени директории называется ncsize. В /etc/system, вы можете попробовать установить
set ncsize = 8192
или даже большее значение. Переменная ядра ufs_inode - которая указыввает на размер кеша inode
зависит от ncsize в Solaris 2.5.1 и более новых. Предыдущие версии Solaris требовали,
чтобы оба параметра устанавливались независимо, но теперь не рекомендуется менять
значение ufs_inode непосредественно на 2.5.1 и более новых.
Вы можете указать ncsize достаточно большим, но в некоторых случаях, в зависимости от приложения, слишком большой ncsize увеличит время отклика при запросе.
Значения по умолчанию:
Solaris 2.5.1 : (max_nprocs + 16 + maxusers) + 64
Solaris 2.6/Solaris 7 : 4 * (max_nprocs + maxusers) + 320
Другой новой настраиваемой возможностью (фактически переключаемой) в Solaris 2.5.1, 2.6 или Solaris 7 есть алгоритм priority_paging. На самом деле это полностью переписанная система виртуальной памяти в Solaris. Он будет выгружать данные приложений последними, а страницы файловой системы - первыми, если вы включите этот алгоритм (установите priority_paging = 1 в /etc/system). Как вам известно, буфер кеша в Solaris растет до заполнения доступных станиц и под старой системой VM, приложения могли выгружаться из памяти, чтобы оставить доступным буфер кеша, что могло привести к засорению свопа и ухудшению производительности приложений. Новый алгоритм priority_paging помогает сохранить приложения и разделяемые библиотеки в памяти, предотвращает переполнение ими буфера кеша, пока памяти ДЕЙСТВИТЕЛЬНО на становится мало. Solaris 2.5.1 требйется патч 103640-25 или новее, а Solaris 2.6 требйется патч 105181-10 или более свежий, чтобы получить функциональность priority_paging. Solaris 7 не тпребует патчей, но этот параметр во всех версиях по умолчанию выключен.
Нами обнаружено, что FreeBSD-2.2.2-RELEASE содержит ряд багов связанных с T/TCP. FreeBSD попытается использовать T/TCP, если вы включили ``TCP Extensions.'' Чтобы выключить T/TCP, используйте sysinstall для деактивации TCP Extensions или отредактируйте /etc/rc.conf, установив
tcp_extensions="NO" # Allow RFC1323 & RFC1544 extensions (or NO).
или добавьте в ваш файл /etc/rc следующее:
sysctl -w net.inet.tcp.rfc1644=0
Нами замечена странная вещь с некторыми межпроцессорными взаимодействиями Squid-а. Зачастую исходящие от процесса dnsserver данные НЕ могут быть прочитаны за один раз. При полной отладке, это выглядит так:
1998/04/02 15:18:48| comm_select: FD 46 ready for reading 1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (100 bytes) 1998/04/02 15:18:48| ipcache_dnsHandleRead: Incomplete reply ....other processing occurs... 1998/04/02 15:18:48| comm_select: FD 46 ready for reading 1998/04/02 15:18:48| ipcache_dnsHandleRead: Result from DNS ID 2 (9 bytes) 1998/04/02 15:18:48| ipcache_parsebuffer: parsing: $name www.karup.com $h_name www.karup.inter.net $h_len 4 $ipcount 2 38.15.68.128 38.15.67.128 $ttl 2348 $end
Интересно, что чаще всего за первый раз удается прочитать только 100 байт. Когда требуется вызвать read() второй раз, это вносит дополнительную задержку в общую обработку запроса. На вашем кеше, запущенном на Digital Unix, среднее время ответа dnsserver составляет 0.01 секунды. Однако, на нашем кеше под FreeBSD средняя задерка составляет 0.10 секунды.
Вот простой патч, исправляющий эту ошибку:
===================================================================
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.40
retrieving revision 1.41
diff -p -u -r1.40 -r1.41
--- src/sys/kern/uipc_socket.c 1998/05/15 20:11:30 1.40
+++ /home/ncvs/src/sys/kern/uipc_socket.c 1998/07/06 19:27:14 1.41
@@ -31,7 +31,7 @@
* SUCH DAMAGE.
*
* @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
- * $Id: FAQ.sgml,v 1.106 2002/01/13 20:08:00 wessels Exp $
+ * $Id: FAQ.sgml,v 1.106 2002/01/13 20:08:00 wessels Exp $
*/
#include <sys/param.h>
@@ -491,6 +491,7 @@ restart:
mlen = MCLBYTES;
len = min(min(mlen, resid), space);
} else {
+ atomic = 1;
nopages:
len = min(min(mlen, resid), space);
/*
Другой способ, который может помочь, правда не исправит ошибки - увеличить размер mbuf в ядре. По умолчанию он равен 128 байтам. Параметр MSIZE объявлен в /usr/include/machine/param.h. Чтобы изменить его, мы добавили следующую строку в конфигурационный файл ядра:
options MSIZE="256"
В /var/yp/Makefile есть такая секция:
# The following line encodes the YP_INTERDOMAIN key into the hosts.byname
# and hosts.byaddr maps so that ypserv(8) will do DNS lookups to resolve
# hosts not in the current domain. Commenting this line out will disable
# the DNS lookups.
B=-b
Вы можете закоментировать строку B=-b, после чего ypserv не будет
производить поиска по DNS.
Squid требует, чтобы был настроен и активен интерфейс обратной петли. Если это не сделано, то вы получите сообщение о ошибке типа commBind.
Решение: Предполгагаем что вообщем вы знакомы с этой проблемой, откройте файл /etc/rc.conf и найдите переменную network_interfaces. В ее значениях измените слово auto на lo0, т.к. слово не активирует интерфейс обратной петли правильно, по уже определенным причинам. Т.к. ваши другие интерфейсы уже были описаны в переменной network_interfaces после инсталяции, то имеет смысл просто сделать s/auto/lo0/ в rc.conf.
Благодарность Robert Lister.
FreeBSD 3.x и более новые поддерживают Softupdates. Это механизм увеличения скорости записи на диск подобно тому как это достигается за счет монтирования томов ufs в асинхронном режиме. Однако, Softupdates делает нечто подобное таким же качеством или даже лучшим, чем может быть достигнуто при использовании асихронного режима, но без потери безопасности в случае краха системы. Для более подробной информации, а также правах использования, см. /sys/contrib/softupdates/README и /sys/ufs/ffs/README.softupdate.
Чтобы система поддерживала softupdates, вам необходимо пересобрать
ядро с директивой options SOFTUPDATES (см. LINT для комментариев
этого примера). После перезагрузки с новым ядром вы можете включить softupdates на основной
файловой системе, следующей командой:
$ tunefs -n /mountpoint
Файловая система НЕ ДОЛЖНА быть подмонитрована в этот момент. После этого softupdates будет
работать и файловая система может быть смонтирована обычным способом. Чтобы проверить, что код
softupdates работает, просто используйте команду mount, ее вывод будет примерно таким:
$ mount
/dev/da2a on /usr/local/squid/cache (ufs, local, noatime, soft-updates, writes: sync 70 async 225)
Некоторые пользователи сообщают о проблемах со Squid, который запущен в окружении jail. Сообщения от Squid в логе выглядят так:
2001/10/12 02:08:49| comm_udp_sendto: FD 4, 192.168.1.3, port 53: (22) Invalid argument 2001/10/12 02:08:49| idnsSendQuery: FD 4: sendto: (22) Invalid argument
Вы можете избавится от этой проблемы указав адрес сетевого интерфейса jail в конфигурационной опции 'udp_outgoing_addr' файла squid.conf.
Если вы компилируете и libgnumalloc.a и Squid при помощи cc, то функция mstats() возвращает неверные значения. Однако, если вы компилируете libgnumalloc.a при помощи gcc, а Squid при помощи cc, то значения верны.
некоторые люди сообщают о трудностях при компиляции Squid на BSD/OS.
Я заметил, что мой процесс Squid упорно продолжает работать с приоритетом 4-ре, и возвращается к нему даже после того как я указываю ему более высокий приоритет. Однако, просмотрев исходный код Squid, я не смог найти никакого примера вызова setpriority() или чего-либо еще, что могло бы указывать Squid-у придерживаться собственного приоритета.
от Bill Bogstad
BSD Юникс традиционно автоматически указывает приоритет нерутовым процессам со значением 4 после того, как они использовали кол-во (4 минуты ???) времени CPU. Мое предположение - это делает BSD/OS, а не Squid. Я вообще не знаю есть ли способ отключить это в BSD/OS.
от Arjan de Vet
Вы можете избежать этого, если запустите Squid с nice-level -4 (или другим отрицательным значением).
Такое поведение - это пережиток истории BSD как университетской ОС. Штрафуются задачи использующие CPU при помощи приоритета после использования ими 600 секунд времени CPU. Добавление
sysctl -w kern.autonicetime=0
в /etc/rc.local должно отключить подобное поведение системы.
Попробуйте другую версию Linux. Мы получили большое количество сообщений о этой ``ошибке'' от людей работающих под Linux 2.0.30. Системный вызов bind(2) НИКОГДА не должен получать подобное сообщение о ошибке при привязке к порту 0.
Некоторые люди сообщали о том, что установка cache_effective_user в
nobody под Linux не работает.
Однако если использовать значение cache_effective_user отличное от
nobody, то все работает как надо. Одно из решений - создать пользователя
для Squid и указать это значение в cache_effective_user. Также вы можете
изменить UID для учетной записи nobody с 65535 на 65534.
Совсем другая проблема - неверная обработка функции setresuid() в RedHat 5.0 Linux. Есть два способа исправить это. Перед запуском configure сделайте следующее:
% setenv ac_cv_func_setresuid no
% ./configure ...
% make clean
% make install
После отрабоки configure отредактируйте файл include/autoconf.h, изменив
строку HAVE_SETRESUID на:
#define HAVE_SETRESUID 0
Также некторые люди сообщают о том, что эта проблема возникает из-за настроек NIS. Проблема исчезает при добавлении compat в строки passwd и group файла /etc/nsswitch.conf ( Ambrose Li).
Russ Mellon отмечает, что данная проблема с cache_effective_user исправлена а в ядрах версии 2.2.x Linux.
Библиотека регулярных выражений, идущая в поставке с Linux, как известно достаточно медленна в работе. Некоторые люди сообщают, что она полностью прекращает рработать через долгий промежуток времени.
Чтобы исправить положение, используйте библиотеку GNUregex, которая включена в исходные тексты Squid. Для Squid-2 используйте ключ конфигурации --enable-gnuregex.
от Radu Greab
При работе функии gethostbyname() наблюдается утечка памяти в RedHat 6.0 с glibc 2.1.1. быстрее всего исправляется уданиеем сервиса nisplus из записи хоста в /etc/nsswitch.conf. При тестировании использование памяти dnsserver снова стабилизировалось после внесения указанных выше изменеий.
См. RedHat bug id 3919.
Некторые ранние версии Linux имеют баг в ядре, вызывающийhave эту проблему. Все что нужно - свежее ядро, в котором нет этого бага.
Это ошибка в некоторых версиях glibc. Заголовки glibc некорректно связаны с содержимым некоторых заголовочных файлов ядра. Все сломалось, когда разработчики ядра немного поправили определенные файлы заголовков ядра.
Мы думаем, что это ошибка в glibc, которая присутствует в версиях 2.1.1 (или 2.1.0) и более ранних. Есть два метода решения проблемы:
Когда используется Squid, при соединении с некоторыми сайтами возникют ошибки тип ``(111) Connection refused'' или ``(110) Connection timed out'', хотя эти сайты нормально работают, если не использовать Squid.
Некторые версии linux используют Explicit Congestion Notification (ECN) и это может быть причиной неудавшихся TCP-соединений, когда происходит обращние к к сайтам с "кривым" файерволом или неверно работающим TCP/IP.
Чтобы работать с подобными "сбоящими" сайтами вы можете выключить использование ECN при помощи следующей команды:
echo 0 >/proc/sys/net/ipv4/tcp_ecn
Вот что было найдено в списке рассылки FreeBSD:
From: Robert Watson
Как уже было указано Bill Fumerola (я подумал, что немного детилизирую пояснения), наблюдаемое вами - есть результат ошибки в коде FreeBSD IPFW. Во FreeBSD сделано прямое сравнение поля флага заголовка TCP и внутреннего поля в структуре, описывающей правило IPFW. К сожалению в некоторый момент, кто-то решил переписать описание структуры правила IPFW, чтобы добавить флаг определяющий "ESTABLISHED". Они использовали значение флага, кторое раньше не применялось протоколом TCP (which doesn't make it safer, just less noticeable). Позже, когда этот флаг был использован для ECN (Endpoint Congestion Notification) в TCP и Linux начал использовать ECN по умолчанию, пакеты стали совпадать с правилами ESTABLISHED независимо от других флагов заголовка TCP. Эта ошибка была исправлена в RELENG_4 branch и был выпущен соответствующий бюллетень безопасности. Нет необходимости говорить о том, что это была достаточно серьезная обшибка, что является хорошим примером, почему вы должны быть очень внимательны при сравнении всего нескольких необходимых вам бит и должныв различать статус пакета от статуса протокола в управляющих структурах, а также проводить расширенное тестирование, чтобы удостовериться, что правила действительно обладают свойствами, которые вы описываете.
См. также thread on the NANOG mailing list, RFC3168 "The Addition of Explicit Congestion Notification (ECN) to IP, PROPOSED STANDARD" или Sally Floyd's page on ECN and problems related to it
Была такая таинственная и необяснимая ошибка в GCC на HP-UX. Некторые функции, определенные как static, вызывали ошибку вычисления. Компилятор таже не мог верно обработать преобразования int-double. Эта ошибка должна быть корректно обработана ыв в версии Squid 2.2.
Эта проблема связанная с GCC (2.8.1 и более ранних) на Irix 6, которая приводит к тому, что всегда возвращается строка 255.255.255.255 для _ЛЮБОГО_ адреса при вызове inet_ntoa(). Если это происходит у вас, откомпилируйте Squid при помощи родного C-компилятора взамен GCC.
от F.J. Bosscha
Чтобы заставить squid нормально запускаться на SCO-unix, вам необходимо сделать следующее:
Увеличьте параметр NOFILES, а также параметр NUMSP и откомпилируйте squid как это сделал я, хотя squid и выдаст в файл cache.log, что ему доступно 3000 файловых дескрипторов, проблема с сообщениями о том, что не хватает файловых дескриптров все еще остается. После того, как я увеличиваю значение NUMSP проблемы исчезают.
Единственное, что остается - кол-во tcp-соединений, поддерживаемых системой. По умолчанию это 256, но я увеличиваю это значение из-за кол-ва клиентов, которые у нас есть.
32-bit processes on AIX and later are restricted by default to a maximum
of 11 shared memory segments. Это органичение может быть удалено на AIX 4.2.1
и более поздних версиях установкой переменной окружения EXTSHM=ON в скрипте или
шеле, который запускает Squid.
По модели управления памятью по умолчанию 32-битные процессы не могут использовать более t чем 256MB стека или данных. Чтобы принудительно увеличить адресное пространство для Squid:
LDR_CNTRL,LDR_CNTRL="MAXDATA=0x80000000";
или-bmaxdata:0x80000000; или