URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 91108
[ Назад ]
Исходное сообщение
"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 09-Мрт-11 14:10 
О преимуществах 64-битовых систем рассказано более чем достаточно, но хочу рассказать о практических результатах в своих конкретных случаях для CentOS.


1. Ранее на веб-серваках всегда пользовался 32-битовым CentOS, и проблем практически не было.

2. В прошлом году установил на 64-битовый CentOS (5.3, что ли, точно уже не помню) на Xeon с 8 Гб памяти.
И сразу наткнулся на проблему - Апач периодически (раз в несколько дней) регулярно падал. Воевал с ним, наверное, с месяц, изучая логи и пытаясь докопаться до причины. Оказалось, что виноват не столько Апач, а библиотека Zend.
Проблему удалось решить, подобрав фактически наугад, метом тыка, сторонние сборки Апача, Zend и еще какие-то либы, которые "подружились".
После этого ЦентОС/64 работает до сих пор, но неприятный осадок остался, тем более, что ухлопал на решение этой проблемы, нигде не описанной, уйму времени.

3. Позавчера установил на мини-материнку Intel DH57JG с 8 метрами CentOS 5.5.
В Биосе был включен режим AHCI для получения NCQ и использовались два жестких диска для получения программного RAID 1.
По недосмотру взял не тот компакт-диск, и установил 32-битную версию, заметил лишь, когда приступил к тестированию системы.
Тестирование прошло успешно, и тогда вчера ночью установил 64-битовый CentOS 5.5
Оставил сервак ночь крутится. Смотрю утром - и что же я вижу?

На экране консоли вот такая хрень - http://savepic.org/1447323.png
а в логах, извините, вот такая пои$ень:
(начало пропускаю)

Mar  9 03:08:50 server smartd[2763]: Device: /dev/sdb, is SMART capable. Adding to "monitor" list.
Mar  9 03:08:50 server smartd[2763]: Monitoring 0 ATA and 2 SCSI devices
Mar  9 03:08:51 server smartd[2765]: smartd has fork()ed into background mode. New PID=2765.
Mar  9 04:05:08 server init: Trying to re-exec init
Mar  9 04:18:50 server kernel: md: delaying resync of md0 until md2 has finished resync (they share one or more physical units)
Mar  9 04:18:50 server kernel: md: delaying resync of md1 until md2 has finished resync (they share one or more physical units)
Mar  9 04:18:50 server kernel: md: delaying resync of md0 until md1 has finished resync (they share one or more physical units)
Mar  9 04:22:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.
Mar  9 04:22:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:22:02 server kernel: md0_resync    D ffffffff80150939     0  4273     87          4274  2389 (L-TLB)
Mar  9 04:22:02 server kernel:  ffff810208479d70 0000000000000046 0000000000000000 ffff81021a97880c
Mar  9 04:22:02 server kernel:  ffff81021a97860c 0000000000000009 ffff81021bec90c0 ffff8102181d0860
Mar  9 04:22:02 server kernel:  000003deef5eeae0 000000000000147b ffff81021bec92a8 0000000000000000
Mar  9 04:22:02 server kernel: Call Trace:
Mar  9 04:22:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:22:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:22:02 server kernel:  [<ffffffff80062ff8>] thread_return+0x62/0xfe
Mar  9 04:22:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:22:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:22:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:22:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:22:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:22:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:22:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:22:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:22:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:22:02 server kernel:
Mar  9 04:22:02 server kernel: INFO: task md1_resync:4274 blocked for more than 120 seconds.
Mar  9 04:22:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:22:02 server kernel: md1_resync    D ffffffff80150939     0  4274     87                4273 (L-TLB)
Mar  9 04:22:02 server kernel:  ffff810203c6bd70 0000000000000046 ffff81000100dd80 ffff81021a97860c
Mar  9 04:22:02 server kernel:  ffff81021a97820c 0000000000000009 ffff81021be47860 ffff81021bc0f100
Mar  9 04:22:02 server kernel:  000003deef5ed6d3 00000000000020a8 ffff81021be47a48 000000018008b4d7
Mar  9 04:22:02 server kernel: Call Trace:
Mar  9 04:22:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:22:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:22:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:22:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:22:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:22:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:22:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:22:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:22:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:22:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:22:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:22:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:22:02 server kernel:
Mar  9 04:24:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.
Mar  9 04:24:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:24:02 server kernel: md0_resync    D ffffffff80150939     0  4273     87          4274  2389 (L-TLB)
Mar  9 04:24:02 server kernel:  ffff810208479d70 0000000000000046 0000000000000000 ffff81021a97880c
Mar  9 04:24:02 server kernel:  ffff81021a97860c 0000000000000009 ffff81021bec90c0 ffff8102181d0860
Mar  9 04:24:02 server kernel:  000003deef5eeae0 000000000000147b ffff81021bec92a8 0000000000000000
Mar  9 04:24:02 server kernel: Call Trace:
Mar  9 04:24:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:24:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:24:02 server kernel:  [<ffffffff80062ff8>] thread_return+0x62/0xfe
Mar  9 04:24:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:24:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:24:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:24:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:24:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:24:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:24:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:24:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:24:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:24:02 server kernel:
Mar  9 04:24:02 server kernel: INFO: task md1_resync:4274 blocked for more than 120 seconds.
Mar  9 04:24:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:24:02 server kernel: md1_resync    D ffffffff80150939     0  4274     87                4273 (L-TLB)
Mar  9 04:24:02 server kernel:  ffff810203c6bd70 0000000000000046 ffff81000100dd80 ffff81021a97860c
Mar  9 04:24:02 server kernel:  ffff81021a97820c 0000000000000009 ffff81021be47860 ffff81021bc0f100
Mar  9 04:24:02 server kernel:  000003deef5ed6d3 00000000000020a8 ffff81021be47a48 000000018008b4d7
Mar  9 04:24:02 server kernel: Call Trace:
Mar  9 04:24:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:24:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:24:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:24:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:24:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:24:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:24:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:24:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:24:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:24:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:24:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:24:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:24:02 server kernel:
Mar  9 04:26:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.
Mar  9 04:26:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:26:02 server kernel: md0_resync    D ffffffff80150939     0  4273     87          4274  2389 (L-TLB)
Mar  9 04:26:02 server kernel:  ffff810208479d70 0000000000000046 0000000000000000 ffff81021a97880c
Mar  9 04:26:02 server kernel:  ffff81021a97860c 0000000000000009 ffff81021bec90c0 ffff8102181d0860
Mar  9 04:26:02 server kernel:  000003deef5eeae0 000000000000147b ffff81021bec92a8 0000000000000000
Mar  9 04:26:02 server kernel: Call Trace:
Mar  9 04:26:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:26:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:26:02 server kernel:  [<ffffffff80062ff8>] thread_return+0x62/0xfe
Mar  9 04:26:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:26:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:26:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:26:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:26:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:26:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:26:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:26:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:26:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:26:02 server kernel:
Mar  9 04:26:02 server kernel: INFO: task md1_resync:4274 blocked for more than 120 seconds.
Mar  9 04:26:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:26:02 server kernel: md1_resync    D ffffffff80150939     0  4274     87                4273 (L-TLB)
Mar  9 04:26:02 server kernel:  ffff810203c6bd70 0000000000000046 ffff81000100dd80 ffff81021a97860c
Mar  9 04:26:02 server kernel:  ffff81021a97820c 0000000000000009 ffff81021be47860 ffff81021bc0f100
Mar  9 04:26:02 server kernel:  000003deef5ed6d3 00000000000020a8 ffff81021be47a48 000000018008b4d7
Mar  9 04:26:02 server kernel: Call Trace:
Mar  9 04:26:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:26:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:26:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:26:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:26:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:26:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:26:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:26:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:26:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:26:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:26:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:26:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:26:02 server kernel:
Mar  9 04:28:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.
Mar  9 04:28:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:28:02 server kernel: md0_resync    D ffffffff80150939     0  4273     87          4274  2389 (L-TLB)
Mar  9 04:28:02 server kernel:  ffff810208479d70 0000000000000046 0000000000000000 ffff81021a97880c
Mar  9 04:28:02 server kernel:  ffff81021a97860c 0000000000000009 ffff81021bec90c0 ffff8102181d0860
Mar  9 04:28:02 server kernel:  000003deef5eeae0 000000000000147b ffff81021bec92a8 0000000000000000
Mar  9 04:28:02 server kernel: Call Trace:
Mar  9 04:28:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:28:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:28:02 server kernel:  [<ffffffff80062ff8>] thread_return+0x62/0xfe
Mar  9 04:28:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:28:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:28:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:28:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:28:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:28:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:28:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:28:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:28:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:28:02 server kernel:
Mar  9 04:28:02 server kernel: INFO: task md1_resync:4274 blocked for more than 120 seconds.
Mar  9 04:28:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:28:02 server kernel: md1_resync    D ffffffff80150939     0  4274     87                4273 (L-TLB)
Mar  9 04:28:02 server kernel:  ffff810203c6bd70 0000000000000046 ffff81000100dd80 ffff81021a97860c
Mar  9 04:28:02 server kernel:  ffff81021a97820c 0000000000000009 ffff81021be47860 ffff81021bc0f100
Mar  9 04:28:02 server kernel:  000003deef5ed6d3 00000000000020a8 ffff81021be47a48 000000018008b4d7
Mar  9 04:28:02 server kernel: Call Trace:
Mar  9 04:28:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:28:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:28:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:28:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:28:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:28:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:28:03 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:28:03 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:28:03 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:28:03 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:28:03 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:28:03 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:28:03 server kernel:
Mar  9 04:30:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.
Mar  9 04:30:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:30:02 server kernel: md0_resync    D ffffffff80150939     0  4273     87          4274  2389 (L-TLB)
Mar  9 04:30:02 server kernel:  ffff810208479d70 0000000000000046 0000000000000000 ffff81021a97880c
Mar  9 04:30:02 server kernel:  ffff81021a97860c 0000000000000009 ffff81021bec90c0 ffff8102181d0860
Mar  9 04:30:02 server kernel:  000003deef5eeae0 000000000000147b ffff81021bec92a8 0000000000000000
Mar  9 04:30:02 server kernel: Call Trace:
Mar  9 04:30:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:30:02 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:30:02 server kernel:  [<ffffffff80062ff8>] thread_return+0x62/0xfe
Mar  9 04:30:02 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:30:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:30:02 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:30:02 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:30:02 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:30:02 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:30:02 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:30:02 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:30:02 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:30:02 server kernel:
Mar  9 04:30:02 server kernel: INFO: task md1_resync:4274 blocked for more than 120 seconds.
Mar  9 04:30:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar  9 04:30:02 server kernel: md1_resync    D ffffffff80150939     0  4274     87                4273 (L-TLB)
Mar  9 04:30:02 server kernel:  ffff810203c6bd70 0000000000000046 ffff81000100dd80 ffff81021a97860c
Mar  9 04:30:02 server kernel:  ffff81021a97820c 0000000000000009 ffff81021be47860 ffff81021bc0f100
Mar  9 04:30:02 server kernel:  000003deef5ed6d3 00000000000020a8 ffff81021be47a48 000000018008b4d7
Mar  9 04:30:02 server kernel: Call Trace:
Mar  9 04:30:03 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:30:03 server kernel:  [<ffffffff8021af66>] md_do_sync+0x1d8/0x833
Mar  9 04:30:03 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:30:03 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:30:03 server kernel:  [<ffffffff8021b93a>] md_thread+0xf8/0x10e
Mar  9 04:30:03 server kernel:  [<ffffffff800a0b5f>] autoremove_wake_function+0x0/0x2e
Mar  9 04:30:03 server kernel:  [<ffffffff8021b842>] md_thread+0x0/0x10e
Mar  9 04:30:03 server kernel:  [<ffffffff8003296e>] kthread+0xfe/0x132
Mar  9 04:30:03 server kernel:  [<ffffffff8005dfb1>] child_rip+0xa/0x11
Mar  9 04:30:03 server kernel:  [<ffffffff800a0947>] keventd_create_kthread+0x0/0xc4
Mar  9 04:30:03 server kernel:  [<ffffffff80032870>] kthread+0x0/0x132
Mar  9 04:30:03 server kernel:  [<ffffffff8005dfa7>] child_rip+0x0/0x11
Mar  9 04:30:03 server kernel:
Mar  9 06:10:50 server kernel: md: md2: sync done.
Mar  9 06:10:50 server kernel: md: delaying resync of md0 until md1 has finished resync (they share one or more physical units)
Mar  9 06:10:50 server kernel: md: syncing RAID array md1
Mar  9 06:10:50 server kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Mar  9 06:10:50 server kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
Mar  9 06:10:50 server kernel: RAID1 conf printout:
Mar  9 06:10:50 server kernel:  --- wd:2 rd:2
Mar  9 06:10:50 server kernel: md: using 128k window, over a total of 8388544 blocks.
Mar  9 06:10:50 server kernel:  disk 0, wo:0, o:1, dev:sda3
Mar  9 06:10:50 server kernel:  disk 1, wo:0, o:1, dev:sdb3
Mar  9 06:11:54 server kernel: md: md1: sync done.
Mar  9 06:11:54 server kernel: md: syncing RAID array md0
Mar  9 06:11:54 server kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Mar  9 06:11:54 server kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
Mar  9 06:11:54 server kernel: md: using 128k window, over a total of 307136 blocks.
Mar  9 06:11:54 server kernel: RAID1 conf printout:
Mar  9 06:11:54 server kernel:  --- wd:2 rd:2
Mar  9 06:11:54 server kernel:  disk 0, wo:0, o:1, dev:sda2
Mar  9 06:11:54 server kernel:  disk 1, wo:0, o:1, dev:sdb2
Mar  9 06:11:56 server kernel: md: md0: sync done.
Mar  9 06:11:56 server kernel: RAID1 conf printout:
Mar  9 06:11:56 server kernel:  --- wd:2 rd:2
Mar  9 06:11:56 server kernel:  disk 0, wo:0, o:1, dev:sda1
Mar  9 06:11:56 server kernel:  disk 1, wo:0, o:1, dev:sdb1


И что об этом всем надо думать?

С одной стороны, это не фатальные ошибки, и вообще даже не ошибки, а просто предупреждающие сообщения.
О чем они говорят, мне трудно судить, но они мне почему-то не нравятся, потому что сразу вспоминается затяжная борьба с падучим Апачем и иже с ним.
Может, стоит послать подальше эти глюкавые 64 бита в исполнении CentOS-компани и вернуться на привычные 32 бита (потеряв несколько в производительности)?

Что скажут гуру?
Очень важно сейчас сделать правильный выбор, потому что потом, когда все сайты будут запущены на орбиту, откатываться назад будет очень тяжко.

Содержание
Сообщения в этом обсуждении
"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено juriskr , 09-Мрт-11 15:04 
Если честно, то не особо понимаю связь с 64бит системами ?
Смотрим:
Mar  9 04:18:50 server kernel: md: delaying resync of md0 until md2 has finished resync (they share one or more physical units)
Mar  9 04:18:50 server kernel: md: delaying resync of md1 until md2 has finished resync (they share one or more physical units)
Mar  9 04:18:50 server kernel: md: delaying resync of md0 until md1 has finished resync (they share one or more physical units)
Mar  9 04:22:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.
Mar  9 04:22:02 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

1.
мд0 откладыбаетца до того как мд2 закончит ресинк
мд1 откладыбаетца до того как мд2 закончит ресинк

2.
Затем смотрим мд0_ресинк бил заблокирован на 120 секунд и предпологаетца что программа зависла (хотя она просто ждет 1. пункта)
Затем смотрим мд1_ресинк бил заблокирован на 120 секунд и предпологаетца что программа зависла (хотя она просто ждет 1. пункта)

Еси посмотреть, то сообщения с трейсбэком повторяютца через каждие 120 секунд, смотреть /proc/sys/kernel/hung_task_timeout_secs


>[оверквотинг удален]
> С одной стороны, это не фатальные ошибки, и вообще даже не ошибки,
> а просто предупреждающие сообщения.
> О чем они говорят, мне трудно судить, но они мне почему-то не
> нравятся, потому что сразу вспоминается затяжная борьба с падучим Апачем и
> иже с ним.
> Может, стоит послать подальше эти глюкавые 64 бита в исполнении CentOS-компани и
> вернуться на привычные 32 бита (потеряв несколько в производительности)?
> Что скажут гуру?
> Очень важно сейчас сделать правильный выбор, потому что потом, когда все сайты
> будут запущены на орбиту, откатываться назад будет очень тяжко.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 09-Мрт-11 15:09 
> Если честно, то не особо понимаю связь с 64бит системами ?

Ну как непонятно, написал выше, что с 32-битами такого не происходит, т.е. все тихо и спокойно.

А тут, как только переехал на 64-битку - к чему эти коллтрейсы, что они означают - аномалию работы в системе?


PS. Конечно, дело не в самих 64 битах, а их исполнении в конкретной ОС - CentOS/64.
Стабильная "недовыпечка" качества 64-битового ядра, имхо - разве не так?

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено desenix , 09-Мрт-11 15:36 
не гуру, попробуйте другие ОС 64 бит, ставил федорино горе на локальном сервере, нагрузки ни какой, но вроде и не падает, работает уже несколько месяцев не отключаясь.
правда памяти гиг всего.
Можно и другие попробовать, но тут я не советчик.
"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено juriskr , 09-Мрт-11 15:43 
сделайте "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" и попробуйте повторите ресинк. думаю все будет хорошо.

>> Если честно, то не особо понимаю связь с 64бит системами ?
> Ну как непонятно, написал выше, что с 32-битами такого не происходит, т.е.
> все тихо и спокойно.
> А тут, как только переехал на 64-битку - к чему эти коллтрейсы,
> что они означают - аномалию работы в системе?
> PS. Конечно, дело не в самих 64 битах, а их исполнении в
> конкретной ОС - CentOS/64.
> Стабильная "недовыпечка" качества 64-битового ядра, имхо - разве не так?

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 09-Мрт-11 16:12 
> сделайте "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" и попробуйте повторите ресинк.
> думаю все будет хорошо.

juriskr:

Ок, допустим, все это сделаю и на какое-то время все "будет хорошо".
Но меня беспокоит эти возникшие CallTrace  - ведь неспроста они появились, причем на голом Центосе, на котором, кроме апдейта, еще не было ничего установлено?
Значит, тому была веская причина. Какая? Какова гарантия, что они не повторятся?
А что будет с системой, когда на нее еще навешается мускул, пхп, апач, нжинкс и т.д.?

В-общем, одолевают сомнения в целесообразности перехода на 64-битовый Центос ввиду обнаруженных сообщений и предыдущего негативного опыта.
Ведь по своему поведению и надежности веб-сервер должен быть, как и жена Цезаря, вне подозрений :)

PS. Сорри, но другие ОС не рассматриваю ввиду многолетней привычки работать исключительно на CentOS.
Ну разве что можно поглядеть на Scientific, но кто знает, отличаются ли он в лучшую сторону.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено juriskr , 09-Мрт-11 17:03 
Если вы так печетес начет доступности, то использование одного сервера уже заведеомо неверний подход. Извините за оффтопик.
Калл трэйцы показивают вам процесс, который по мнению системи повис. В данном случае однозначно видно что процесс не повис а ожидает окончания синхронизации мд2. Ожидание длилось больще 120 секунд, поэтому система предположила что процесс повис. (Смотреть предидущий пост как отключить такое поведение).

Не хвастобства ради:
Linux hostname 2.6.18-164.2.1.el5.028stab066.10 #1 SMP Sat Dec 12 18:52:53 MSK 2009 x86_64 x86_64 x86_64 GNU/Linux
16:00:55 up 295 days, 22:15,  1 user,  load average: 0.66, 0.85, 1.06
CentOS release 5.2 (Final)
model name    : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
model name    : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
model name    : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
model name    : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz


>[оверквотинг удален]
> А что будет с системой, когда на нее еще навешается мускул, пхп,
> апач, нжинкс и т.д.?
> В-общем, одолевают сомнения в целесообразности перехода на 64-битовый Центос ввиду обнаруженных
> сообщений и предыдущего негативного опыта.
> Ведь по своему поведению и надежности веб-сервер должен быть, как и жена
> Цезаря, вне подозрений :)
> PS. Сорри, но другие ОС не рассматриваю ввиду многолетней привычки работать исключительно
> на CentOS.
> Ну разве что можно поглядеть на Scientific, но кто знает, отличаются ли
> он в лучшую сторону.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 09-Мрт-11 17:27 
> Не хвастобства ради:

Ну, 295 дней конечно, хороший показатель :)

У меня Xeon тоже по несколько месяцев работает, но когда выполняю минорный апдейт, все-таки ребутаюсь, для спокойствия ;)

> В данном случае однозначно видно что процесс не повис а ожидает окончания синхронизации мд2.

Тогда подскажите, плиз, по какой причине могла возникнуть надобность в возникшей синхронизации?
Ведь сервер включен под UPS, никакой прикладной софт еще не установлен - и вдруг на тебе!
Не говорит ли это опять-таки о погрешностях в реализации 64-битового ядра Центоса?

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено juriskr , 09-Мрт-11 17:46 
Как вы догадываетесь на вопрос насчет синхронизации я ответить не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего.
Я думаю с 64 битами это никак не связано.

>> Не хвастобства ради:
> Ну, 295 дней конечно, хороший показатель :)
> У меня Xeon тоже по несколько месяцев работает, но когда выполняю минорный
> апдейт, все-таки ребутаюсь, для спокойствия ;)
>> В данном случае однозначно видно что процесс не повис а ожидает окончания синхронизации мд2.
> Тогда подскажите, плиз, по какой причине могла возникнуть надобность в возникшей синхронизации?
> Ведь сервер включен под UPS, никакой прикладной софт еще не установлен -
> и вдруг на тебе!
> Не говорит ли это опять-таки о погрешностях в реализации 64-битового ядра Центоса?

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 09-Мрт-11 17:51 
> не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего.

Это не проблема :)  Что именно нужно сообщить?
Или, если интересно, могу шелл дать :D


"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено juriskr , 10-Мрт-11 10:40 
>> не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего.
> Это не проблема :)  Что именно нужно сообщить?
> Или, если интересно, могу шелл дать :D

Спасибо за преджение, но думаю откажус.
Но я уверен что с 64 битами ето не связано.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено alex , 10-Мрт-11 16:32 
Это "проблема" есть в 64 битной CentOS. Она зачем-то регулярно синхронизирует софтовые RAID массивы.
Было тоже самое на CentOS 5.5 x86-64. После перевода системы на Debian 6 x86-64 (софтовый райд не трогался, так как squeeze его нормально подхватывает при установке системы) такой проблемы больше не наблюдается.
"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено PavelR , 10-Мрт-11 16:56 
> Это "проблема" есть в 64 битной CentOS. Она зачем-то регулярно синхронизирует софтовые
> RAID массивы.
> Было тоже самое на CentOS 5.5 x86-64. После перевода системы на Debian
> 6 x86-64 (софтовый райд не трогался, так как squeeze его нормально
> подхватывает при установке системы) такой проблемы больше не наблюдается.

Debian тоже делает периодическую проверку состояния массива.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 10-Мрт-11 17:30 
> Она зачем-то регулярно синхронизирует софтовые RAID массивы

Знать бы еще зачем. Может, это и хорошо как раз, но тогда варнинги следовало бы сделать более приятными, или убрать их по дефолту вообще.

В-общем, из-за этой неясной ситуации установил Scientific Linux 6.0, пока щупаю, посмотрим, что он споёт.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено Andrey Mitrofanov , 10-Мрт-11 18:47 
> О преимуществах 64-битовых систем рассказано более чем достаточно, но хочу рассказать о
> практических результатах в своих конкретных случаях для CentOS.
> 1. Ранее на веб-серваках всегда пользовался 32-битовым CentOS, и проблем практически не
> было.

[--->8---]

> Что скажут гуру?
> Очень важно сейчас

Гуру скажут, что....

1/ Тема _тягостности_ выбора не раскрыта. Надо так: "Поставил 32 бита, лохпухнулся. Пацаны застебают. Памагииитя!!1"

2/
google:proc/sys/kernel/hung_task_timeout_secs
читать...
google:CONFIG_DETECT_SOFTLOCKUP
читать...
google:task md1_resync:4274 blocked for more than 120 seconds
да, вот же оно...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514627

Требуйте в баг-трекерах своих сентосо-рэдхотов.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено Andrey Mitrofanov , 10-Мрт-11 18:51 
> Требуйте в баг-трекерах своих сентосо-рэдхотов.

Бонус!
google:9744197c3d7b329590c2be33ad7b17409bd798fe
google:9744197c3d7b329590c2be33ad7b17409bd798fe centos

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено chukcha2 , 12-Мрт-11 04:05 
Andrey Mitrofanov:

Что вы хотели своими репликами сказать, непонятно.
Причем тут Дебиан, бонусы....   речь-то шла о Центосе.

"CentOS, тягостный выбор: 64 или 32 бита?"
Отправлено Hammer , 29-Мрт-11 19:54 
> Andrey Mitrofanov:
> Что вы хотели своими репликами сказать, непонятно.
> Причем тут Дебиан, бонусы....   речь-то шла о Центосе.

http://www.google.ru/search?sourceid=chrome&ie=UTF-8&q=97441...