FreeBSD 5.4 с ядром пересобраным под Сквид по ФАКу. Пробовал Squid 2.6.S2/2.6.S4. B Squid используется asinc-io, diskd. Пробовал ещё dlmalloc - не помогло.

B "CacheManager/DISKD Stats" значения FAIL зашкаливают. странно, но раньше (2.5.S13) такого небыло...
-----------------------------------
sent_count: 19354
recv_count: 19354
max_away: 12
max_shmuse: 10
open_fail_queue_len: 0
block_queue_len: 0

              OPS   SUCCESS    FAIL
   open      2769      2610     159
create      1235      1235       0
  close      3845      3845       0
unlink      1911       107    1804
   read      3845      3686       0
  write      5749      5749       0
-----------------------------------

и при этом "Cache Manager/Store IO Interface Stats" - чистый. Как будто Сквид этих фейлов и не замечает...
-------------------
Store IO Interface Stats
create.calls 1236
create.select_fail 0
create.create_fail 0
create.success 1236
open.calls 2769
open.success 2769
open.loadav_fail 0
open.open_fail 0
-------------------

fsck делал - всё чисто. Вот только памяти Сквид отъедает неподецки. Похоже на Memory leak, и похоже что эти две проблемы напрямую взимосвязаны.

Прошу совета у более опытных товарищей...

• B 'CacheManager/DISKD Stats' очень большой unlink/FAIL и Ope...,syrok, 12:36 , 31-Окт-06
• B 'CacheManager/DISKD Stats' очень большой unlink/FAIL и Ope...,whitefox, 11:11 , 09-Ноя-06
  • B 'CacheManager/DISKD Stats' очень большой unlink/FAIL и Ope...,syrok, 11:22 , 09-Ноя-06
    • B 'CacheManager/DISKD Stats' очень большой unlink/FAIL и Ope...,whitefox, 09:30 , 10-Ноя-06
      • B 'CacheManager/DISKD Stats' очень большой unlink/FAIL и Ope...,syrok, 12:06 , 10-Ноя-06
      • B 'CacheManager/DISKD Stats' очень большой unlink/FAIL и Ope...,syrok, 13:37 , 10-Ноя-06

Поигрался с MemoryPools. Squid  стал реже падать, но с ДискД ситуация не изменилась.
Разве никто не мониторит Сквид через КешМенеджер? Ниукого такого небыло?

Так же наблюдается стабильный рост FAIL примерно 1 к 20-ти

>Так же наблюдается стабильный рост FAIL примерно 1 к 20-ти

на какоб билде Сквида наблюдаешь? тоже 2.5.х?
откат на 2.4.х пробовал? потому как по отсутствию ответов в этой теме я уже предполагаю, что проблема в системе, которая у меня была пересобрана под Сквид 2.4....

>>Так же наблюдается стабильный рост FAIL примерно 1 к 20-ти
>
>на какоб билде Сквида наблюдаешь? тоже 2.5.х?
squid 2.6.STABLE5
>откат на 2.4.х пробовал? потому как по отсутствию ответов в этой теме
Нет
>я уже предполагаю, что проблема в системе, которая у меня была
>пересобрана под Сквид 2.4....

Я тут подсмотрел как делают
I have changed following parameters in kernel source before compile it for the
diskd filesystem:
/usr/local/src/linux-2.6/include/linux/msg.h and
#define MSGMNI 40
#define MSGSSZ 40
kernel version is 2.6.17.7 it's compiled with SMP support

FAIL стало на порядок меньше

у меня так и собрано ядро (правда FreeBSD 5.4), даже больше.

options        MSGMNI=40        # Max. number of message queues for the whole system.
options        MSGSSZ=64        # Message segment size.

это указано в факе к Сквиду.

И с этим ядром всё работало прекрасно, пока не перешёл на 2.6.х.

Посмотрел сейчас Кешменеджер - и прослезился.
Ни одной ошибки! На том же билде Сквида 2.6.4, на той же системе.
Иначе как чудесным исцелением это назвать немогу, посколько пока шаманил - стоко всего крутил, курил факи и снова крутил, что всё припомнить немогу.

Есть только подозрение: последний рестарт Сквида был "ручной". Тоесть ручками остановил Сквид, тогда уже рестартнул машину, ну и Сквид по автозапуску завёлся.
Подозрение это потому, что когда сразу рестартовать систему, то скрипт запуска/останова Сквида из /usr/local/etc/rc.d неуспевает погасить Сквид. В результате после перезапуска кеш всегда DIRTY, и идёт его ребилд.

Кстати, это у всех так с автоостановом Сквида при шатдауне системы, или просто у меня такая машинка слабая, что неуспевает этого сделать? (AMD K6-III 450MHz/768M RAM/10Gb IDE UDMA-33 = 20 юзеров)