У меня проблема с сервером debian, которая, как я думал, возникла из-за плохой оперативной памяти, но она сохраняется.
Это Dell Poweredge 6800 с двумя двухъядерными процессорами Xeon 3,6 ГГц и 5 ГБ памяти DDR2 ECC 333.
У меня есть один диск SCSI на 73 ГБ.
Я сейчас работаю до смерти, извлекая записи из MySQL для создания файлов .call звездочки (небольшие текстовые файлы), которые запускают вызовы SIP.
Мы управляем им через интерфейс cgi, и в системе также работает citadel для нашей почты, но у нас меньше пяти пользователей. Это не большая утечка.
Моя пиковая нагрузка составляет около 460 звонков в минуту. Нагрузка колеблется в пределах от 2,0 до 4,3, если я пропущу это значение, она вырастет до> 22,0.
Проблема, с которой я столкнулся, в том, что примерно через час после начала набора я мерзну. Вчера вечером я запустил его в 5:59, и в 6:55:17 секунд система перестала отвечать. Ничего не регистрировалось, я не мог подключиться через ssh или http, он отвечал на ping, а nmap показывал открытые порты, к которым я мог подключиться по telnet, но не получал никакого ответа.
Мой сбор данных sar выполнялся в 6:50, и в то время я наблюдал интенсивное использование, как и ожидалось, но ничего возмутительного, насколько я могу судить.
Система жаловалась на ошибку памяти в одной из новых полос 2 ГБ, которые я установил, поэтому после первого сбоя я заменил эту пару полосами 512 МБ, с которых мы обновились.
Я сейчас набираю номер с работающим сбором данных sar на случай, если он снова выйдет из строя. По крайней мере, я смогу набрать более подробную информацию.
Помимо этого, я не понимаю, как диагностировать зависание системы при отсутствии каких-либо соответствующих данных журнала или аварийного дампа. Поскольку система все еще работает, но полностью не отвечает в течение этого времени, пока я не выполню цикл включения питания. Любые идеи?
ПРИМЕЧАНИЕ. У меня есть новые серверы, чтобы снять часть нагрузки с этой системы за счет распределения услуг, но пока что это среднее время, когда наше производство полагается на эту рабочую лошадку.
Вот данные Sar из крушения Last Night.
ОБНОВИТЬ: Этот снимок sar выполнялся с шагом 10 секунд, последний раз был собран за 1 секунду до зависания
Я приобрел сервер консоли терминала и теперь могу видеть, что происходит, когда система зависает.
Этот набор сообщений просто повторяется каждые 30 секунд или около того, циклически перебирая CPU1 и CPU2.
[17675.940127] BUG: soft lockup - CPU#1 stuck for 61s! [asterisk:4579]
[17675.940127] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs reiserfs ext]
[17675.940127]
[17675.940127] Pid: 4579, comm: asterisk Not tainted (2.6.32-5-686-bigmem #1) PowerEdge 6800
[17675.940127] EIP: 0060:[<c1024c6f>] EFLAGS: 00000202 CPU: 1
[17675.940127] EIP is at native_flush_tlb_others+0x85/0xa6
[17675.940127] EAX: 00000282 EBX: c14620ac ECX: c102fb3a EDX: 00000020
[17675.940127] ESI: 00000001 EDI: 00000040 EBP: c14620a0 ESP: f35d1a3c
[17675.940127] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[17675.940127] CR0: 80050033 CR2: b3f06946 CR3: 36787000 CR4: 000006f0
[17675.940127] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[17675.940127] DR6: ffff0ff0 DR7: 00000400
[17675.940127] Call Trace:
[17675.940127] [<c1024d57>] ? flush_tlb_page+0x5d/0x65
[17675.940127] [<c1024144>] ? ptep_set_access_flags+0x59/0x63
[17675.940127] [<c10a13c8>] ? do_wp_page+0x3b9/0x7dd
[17675.940127] [<c1025a1d>] ? kmap_atomic_prot+0xd7/0xfc
[17675.940127] [<c10a3173>] ? handle_mm_fault+0x982/0xa22
[17675.940127] [<c104d52d>] ? lock_hrtimer_base+0x15/0x2f
[17675.940127] [<c104d5ab>] ? hrtimer_try_to_cancel+0x2f/0x35
[17675.940127] [<c12823e8>] ? do_page_fault+0x2f1/0x307
[17675.940127] [<c12820f7>] ? do_page_fault+0x0/0x307
[17675.940127] [<c1280923>] ? error_code+0x73/0x78
[17675.940127] [<c10c00d8>] ? copy_strings+0x94/0x1ba
[17675.940127] [<c10c6b8a>] ? do_sys_poll+0x2c3/0x312
[17675.940127] [<c10c7586>] ? __pollwait+0x0/0xa5
[17675.940127] [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127] [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127] [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127] [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127] [<c1026614>] ? activate_task+0x1e/0x24
[17675.940127] [<c1032713>] ? push_rt_task+0x208/0x242
[17675.940127] [<c102acb9>] ? post_schedule+0x31/0x3e
[17675.940127] [<c127f5d6>] ? schedule+0x78f/0x7dc
[17675.940127] [<c10567d5>] ? futex_wait_setup+0x5c/0xcd
[17675.940127] [<c10568cd>] ? futex_wait_queue_me+0x87/0x98
[17675.940127] [<c100c96a>] ? sched_clock+0x5/0x7
[17675.940127] [<c1091b00>] ? zone_watermark_ok+0x16/0x99
[17675.940127] [<c1087baa>] ? cpupri_find+0x4c/0xd6
[17675.940127] [<c109270c>] ? get_page_from_freelist+0xc0/0x3c7
[17675.940127] [<c102d917>] ? check_preempt_curr_rt+0x76/0xe3
[17675.940127] [<c1024e31>] ? smp_invalidate_interrupt+0x73/0x86
[17675.940127] [<c1092cd4>] ? __alloc_pages_nodemask+0xf3/0x4d9
[17675.940127] [<c113d358>] ? cpumask_any_but+0x20/0x2b
[17675.940127] [<c1024d44>] ? flush_tlb_page+0x4a/0x65
[17675.940127] [<c127fe16>] ? mutex_lock+0xb/0x24
[17675.940127] [<c10bb225>] ? do_sync_read+0xc0/0x107
[17675.940127] [<c10438d5>] ? do_send_sig_info+0x4f/0x59
[17675.940127] [<c104a97a>] ? autoremove_wake_function+0x0/0x2d
[17675.940127] [<c1051af5>] ? ktime_get_ts+0xcd/0xd5
[17675.940127] [<c10c6d2b>] ? sys_poll+0x44/0x8d
[17675.940127] [<c100813b>] ? sysenter_do_call+0x12/0x28
В первой итерации был указан другой набор модулей.
[267866.376128] Modules linked in: cpufreq_powersave cpufreq_stats cpufreq_conservative cpufreq_userspace parport_pc ppdev lp parport sco bridge stp bnep rfcomm l2cap crc16 bluetooth rfkill nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs binfmt_misc fuse loop radeon ttm psmouse drm_kms_helper serio_raw evdev pcspkr drm i2c_algo_bit rng_core i2c_core dcdbas shpchp button pci_hotplug processor ext3 jbd mbcache sd_mod crc_t10dif sg sr_mod cdrom ata_generic uhci_hcd ata_piix mptspi mptscsih ehci_hcd mptbase usbcore nls_base libata tg3 scsi_transport_spi scsi_mod floppy libphy thermal thermal_sys [last unloaded: scsi_wait_scan]
Я установил intel-microcode microcode.ctl не понял, как отключить гиперпоточность, как предлагали некоторые другие форумы.
Я думаю, что этот шаблон может быть связан с тем, что количество операций ввода-вывода при записи настолько велико, что диски не синхронизируются. Это могло бы объяснить внезапный всплеск нагрузки, во время которого ничего не регистрируется, что в конечном итоге разрешается само собой.
В этом случае / proc / meminfo покажет высокое значение для «Dirty», когда система зависает, и вы можете увидеть сообщения dmesg / syslog, например:
INFO: task syslogd:1500 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syslogd D 0000000000000110 0 1500 1 1503 1491 (NOTLB)
ffff8800b0739d88 0000000000000286 ffff8800b8922970 ffff8800b8922970
0000000000000009 ffff8800bb2dd0c0 ffff8800baa55080 0000000000002b40
ffff8800bb2dd2a8 0000000000000000
Call Trace:
[] :jbd:log_wait_commit+0xa3/0xf5
[] autoremove_wake_function+0x0/0x2e
[] :jbd:journal_stop+0x1cf/0x1ff
[] __writeback_single_inode+0x1d9/0x318
[] do_readv_writev+0x26e/0x291
[] sync_inode+0x24/0x33
[] :ext3:ext3_sync_file+0xcc/0xf8
[] do_fsync+0x52/0xa4
[] __do_fsync+0x23/0x36
[] tracesys+0xab/0xb6
Если это то, что происходит, вам придется найти способ сделать запись менее обременительной, регулируя их, или кешируя их, или, может быть, переключая планировщик диска на noop, или ... и т. Д. эта проблема поможет, потому что система сможет выдерживать большие всплески «грязной» памяти перед зависанием.
Пара вещей, которые вы можете попытаться получить, чтобы получить дополнительную информацию:
Если вы думаете, что ваш сервер полностью падает, вы можете получить информацию от netconsole если по какой-то причине у вас нет доступа к консоли по умолчанию.
Если вы используете Asterisk с флагом -p и он может блокировать систему в реальном времени, вы можете попробовать создать новую оболочку ssh, например: # for pid in `pidof sshd`; do chrt -p -f 99 $pid; done
Вы также можете попробовать установить следующие параметры, чтобы он автоматически перезагружался, если ядро обнаруживает проблему: # sysctl -w kernel.panic_on_oops=1; sysctl -w kernel.panic=1; sysctl -w kernel.softlockup_panic=1.