named и syslog

Он должен писать в лог, поступить правильно, это дать писать дальше в лог =), или у вас с этим проблемы что он пишит в лог отклонённые запросы ?

Если вы альтруист и хотите предоставить мощности своего сервера на благо общественности - то стоит разрешить рекурсивные запросы кому угодно ;)

Кстати, безопасность тоже может пострадать - сейчас как раз много говорят о кешировании ДНС-серверами сфальсифицированных ответов. Эта опция может помочь злоумышленникам.

madoff, ничего страшного, что это все пишется в лог, главное - чтобы не вредило работе сервера. просто уже второй раз сервер падает за неделю. наверно неправильно думать, что это из-за bind...

ладно, тогда не буду париться по этому поводу.

не знаю, создавать ли другую тему... напишу лучше здесь, чтобы не флудить.

вот такие записи в syslog и kern.log:

Apr 26 23:01:05 mgold kernel: [48004.855344] =======================

Apr 26 23:01:07 mgold kernel: [48006.998624] INFO: task apache2:9165 blocked for more than 120 seconds.

Apr 26 23:01:07 mgold kernel: [48006.998641] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Apr 26 23:01:07 mgold kernel: [48006.998653] apache2 D d6715471 0 9165 2481

Apr 26 23:01:07 mgold kernel: [48006.998663] c232a6a0 00200082 c1fdb2f8 d6715471 00002a2d c232a82c c1fde020 00000001

Apr 26 23:01:07 mgold kernel: [48006.998681] 00002a2d 00200282 030a9576 00000000 d6eb2e0f 00002a2d c0123f62 00000000

Apr 26 23:01:07 mgold kernel: [48006.998702] f7137710 f7137718 f7137714 c232a6a0 c02c8df4 c0fc7ed0 c0f61ed0 c232a6a0

Apr 26 23:01:07 mgold kernel: [48006.998724] Call Trace:

Apr 26 23:01:07 mgold kernel: [48006.998752] [<c0123f62>] hrtick_set+0x8f/0xd8

Apr 26 23:01:07 mgold kernel: [48006.998767] [<c02c8df4>] __mutex_lock_slowpath+0x50/0x7b

Apr 26 23:01:07 mgold kernel: [48006.998782] [<c02c8c8a>] mutex_lock+0xa/0xb

Apr 26 23:01:07 mgold kernel: [48006.998790] [<c01844e7>] do_lookup+0x6e/0x153

Apr 26 23:01:07 mgold kernel: [48006.998805] [<c0186121>] __link_path_walk+0x724/0xb0b

Apr 26 23:01:07 mgold kernel: [48006.998822] [<c0174039>] swap_info_get+0x47/0x7a

Apr 26 23:01:07 mgold kernel: [48006.998835] [<c018653f>] path_walk+0x37/0x70

Apr 26 23:01:07 mgold kernel: [48006.998847] [<c01867ee>] do_path_lookup+0x122/0x184

Apr 26 23:01:07 mgold kernel: [48006.998859] [<c018704b>] __user_walk_fd+0x29/0x3a

Apr 26 23:01:07 mgold kernel: [48006.998871] [<c01811ee>] vfs_stat_fd+0x15/0x3c

Apr 26 23:01:07 mgold kernel: [48006.998892] [<c011b395>] do_page_fault+0x4ab/0x8f2

Apr 26 23:01:07 mgold kernel: [48006.998903] [<c01812ca>] sys_stat64+0xf/0x23

Apr 26 23:01:07 mgold kernel: [48006.998923] [<c011aeea>] do_page_fault+0x0/0x8f2

Apr 26 23:01:07 mgold kernel: [48006.998932] [<c0108853>] sysenter_past_esp+0x78/0xb1

Apr 26 23:01:07 mgold kernel: [48006.998953] =======================

Apr 26 23:01:09 mgold kernel: [48009.145474] INFO: task apache2:9793 blocked for more than 120 seconds.

Apr 26 23:01:09 mgold kernel: [48009.145494] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Apr 26 23:01:09 mgold kernel: [48009.145506] apache2 D 22d0c978 0 9793 2481

Apr 26 23:01:09 mgold kernel: [48009.145516] f05f5760 00200082 00000000 22d0c978 00002a4c f05f58ec c1fde020 00000001

Apr 26 23:01:09 mgold kernel: [48009.145534] d0b013c0 c22f9f14 02fb23ab 00000000 c01867ee ebdee000 ffffffe9 00000310

о чем могут говорить? что в ядре бага?

5000 записей за полчаса, все это время сервер был недоступен по SSH, HTTP. но пинговался.

почитал bagtrack для debian, так и понял, как это вылечить...

Если поддерживать актуальность ПО ,всё будет ок.

madoff, я не рискую сам переустанавливать основное ПО, сколько будет стоить поправить данную проблему?

блокировки идут процессов !

Сервер как себя чувствует, диски не нагружены, не зависает ? всё ок с ним ?

LA держится на уровне 1-2-3 (2 ядра), нагрузка небольшая по моим прикидкам...

база MYSQL вообще на другом сервере. фактически на этом сервере работает только апач.

2ГБ оперативной памяти используются всегда на 97%.

в общем-то глюк получается как раз в самый пик посещаемости (по графику li.ru), но это наверно больше совпадение, т.к. с LA даже в 10-20 прошлый сервер отлично жил...

cat /proc/cpuinfo

а nginx ведь нет?

тут похоже из свопа пытались пробудить apache и процесс затянулся

madoff,

processor : 0

vendor_id : AuthenticAMD

cpu family : 15

model : 67

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+

stepping : 3

cpu MHz : 1000.000

cache size : 1024 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 2

apicid : 0

initial apicid : 0

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 1

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy

bogomips : 2063.33

clflush size : 64

power management: ts fid vid ttp tm stc

processor : 1

vendor_id : AuthenticAMD

cpu family : 15

model : 67

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+

stepping : 3

cpu MHz : 1000.000

cache size : 1024 KB

physical id : 0

siblings : 2

core id : 1

cpu cores : 2

apicid : 1

initial apicid : 1

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 1

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy

bogomips : 2063.33

clflush size : 64

power management: ts fid vid ttp tm stc