forum.opennet.ru - "CentOS, тягостный выбор: 64 или 32 бита?" (17)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"CentOS, тягостный выбор: 64 или 32 бита?"

Форум Открытые системы на сервере (Системное и пользовательское ПО / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"CentOS, тягостный выбор: 64 или 32 бита?"	+/–
Сообщение от chukcha2 (ok) on 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 бита (потеряв несколько в производительности)? Что скажут гуру? Очень важно сейчас сделать правильный выбор, потому что потом, когда все сайты будут запущены на орбиту, откатываться назад будет очень тяжко.
Ответить \| Правка \| Cообщить модератору

Оглавление

CentOS, тягостный выбор: 64 или 32 бита?, juriskr, 15:04 , 09-Мрт-11, (1)

CentOS, тягостный выбор: 64 или 32 бита?, chukcha2, 15:09 , 09-Мрт-11, (2)

CentOS, тягостный выбор: 64 или 32 бита?, desenix, 15:36 , 09-Мрт-11, (3)
CentOS, тягостный выбор: 64 или 32 бита?, juriskr, 15:43 , 09-Мрт-11, (4)

CentOS, тягостный выбор: 64 или 32 бита?, chukcha2, 16:12 , 09-Мрт-11, (5)

CentOS, тягостный выбор: 64 или 32 бита?, juriskr, 17:03 , 09-Мрт-11, (6)

CentOS, тягостный выбор: 64 или 32 бита?, chukcha2, 17:27 , 09-Мрт-11, (7)

CentOS, тягостный выбор: 64 или 32 бита?, juriskr, 17:46 , 09-Мрт-11, (8)

CentOS, тягостный выбор: 64 или 32 бита?, chukcha2, 17:51 , 09-Мрт-11, (9)

CentOS, тягостный выбор: 64 или 32 бита?, juriskr, 10:40 , 10-Мрт-11, (10)

CentOS, тягостный выбор: 64 или 32 бита?, alex, 16:32 , 10-Мрт-11, (11)

CentOS, тягостный выбор: 64 или 32 бита?, PavelR, 16:56 , 10-Мрт-11, (12)
CentOS, тягостный выбор: 64 или 32 бита?, chukcha2, 17:30 , 10-Мрт-11, (13)

CentOS, тягостный выбор: 64 или 32 бита?, Andrey Mitrofanov, 18:47 , 10-Мрт-11, (14)

CentOS, тягостный выбор: 64 или 32 бита?, Andrey Mitrofanov, 18:51 , 10-Мрт-11, (15)
CentOS, тягостный выбор: 64 или 32 бита?, chukcha2, 04:05 , 12-Мрт-11, (16)

CentOS, тягостный выбор: 64 или 32 бита?, Hammer, 19:54 , 29-Мрт-11, (17)

Сообщения по теме [Сортировка по времени | RSS]

1. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от juriskr (ok) on 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 бита (потеряв несколько в производительности)?
> Что скажут гуру?
> Очень важно сейчас сделать правильный выбор, потому что потом, когда все сайты
> будут запущены на орбиту, откатываться назад будет очень тяжко.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от chukcha2 (ok) on 09-Мрт-11, 15:09

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

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от desenix (ok) on 09-Мрт-11, 15:36

не гуру, попробуйте другие ОС 64 бит, ставил федорино горе на локальном сервере, нагрузки ни какой, но вроде и не падает, работает уже несколько месяцев не отключаясь.
правда памяти гиг всего.
Можно и другие попробовать, но тут я не советчик.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от juriskr (ok) on 09-Мрт-11, 15:43

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от chukcha2 (ok) on 09-Мрт-11, 16:12

> сделайте "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" и попробуйте повторите ресинк.
> думаю все будет хорошо.
juriskr:
Ок, допустим, все это сделаю и на какое-то время все "будет хорошо".
Но меня беспокоит эти возникшие CallTrace  - ведь неспроста они появились, причем на голом Центосе, на котором, кроме апдейта, еще не было ничего установлено?
Значит, тому была веская причина. Какая? Какова гарантия, что они не повторятся?
А что будет с системой, когда на нее еще навешается мускул, пхп, апач, нжинкс и т.д.?
В-общем, одолевают сомнения в целесообразности перехода на 64-битовый Центос ввиду обнаруженных сообщений и предыдущего негативного опыта.
Ведь по своему поведению и надежности веб-сервер должен быть, как и жена Цезаря, вне подозрений :)
PS. Сорри, но другие ОС не рассматриваю ввиду многолетней привычки работать исключительно на CentOS.
Ну разве что можно поглядеть на Scientific, но кто знает, отличаются ли он в лучшую сторону.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от juriskr (ok) on 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, но кто знает, отличаются ли
> он в лучшую сторону.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от chukcha2 (ok) on 09-Мрт-11, 17:27

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от juriskr (ok) on 09-Мрт-11, 17:46

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

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от chukcha2 (ok) on 09-Мрт-11, 17:51

> не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего.
Это не проблема :)  Что именно нужно сообщить?
Или, если интересно, могу шелл дать :D

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от juriskr (ok) on 10-Мрт-11, 10:40

>> не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего.
> Это не проблема :)  Что именно нужно сообщить?
> Или, если интересно, могу шелл дать :D
Спасибо за преджение, но думаю откажус.
Но я уверен что с 64 битами ето не связано.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от alex (??) on 10-Мрт-11, 16:32

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от PavelR (??) on 10-Мрт-11, 16:56

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от chukcha2 (ok) on 10-Мрт-11, 17:30

> Она зачем-то регулярно синхронизирует софтовые RAID массивы
Знать бы еще зачем. Может, это и хорошо как раз, но тогда варнинги следовало бы сделать более приятными, или убрать их по дефолту вообще.
В-общем, из-за этой неясной ситуации установил Scientific Linux 6.0, пока щупаю, посмотрим, что он споёт.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от Andrey Mitrofanov on 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
Требуйте в баг-трекерах своих сентосо-рэдхотов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от Andrey Mitrofanov on 10-Мрт-11, 18:51

> Требуйте в баг-трекерах своих сентосо-рэдхотов.
Бонус!
google:9744197c3d7b329590c2be33ad7b17409bd798fe
google:9744197c3d7b329590c2be33ad7b17409bd798fe centos

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от chukcha2 (ok) on 12-Мрт-11, 04:05

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "CentOS, тягостный выбор: 64 или 32 бита?" +/–

Сообщение от Hammer (ok) on 29-Мрт-11, 19:54

> Andrey Mitrofanov:
> Что вы хотели своими репликами сказать, непонятно.
> Причем тут Дебиан, бонусы....   речь-то шла о Центосе.
http://www.google.ru/search?sourceid=chrome&ie=UTF-8&q=97441...

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
Сообщение от juriskr (ok) on 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 бита (потеряв несколько в производительности)? > Что скажут гуру? > Очень важно сейчас сделать правильный выбор, потому что потом, когда все сайты > будут запущены на орбиту, откатываться назад будет очень тяжко.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от chukcha2 (ok) on 09-Мрт-11, 15:09
	> Если честно, то не особо понимаю связь с 64бит системами ? Ну как непонятно, написал выше, что с 32-битами такого не происходит, т.е. все тихо и спокойно. А тут, как только переехал на 64-битку - к чему эти коллтрейсы, что они означают - аномалию работы в системе? PS. Конечно, дело не в самих 64 битах, а их исполнении в конкретной ОС - CentOS/64. Стабильная "недовыпечка" качества 64-битового ядра, имхо - разве не так?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от desenix (ok) on 09-Мрт-11, 15:36
	не гуру, попробуйте другие ОС 64 бит, ставил федорино горе на локальном сервере, нагрузки ни какой, но вроде и не падает, работает уже несколько месяцев не отключаясь. правда памяти гиг всего. Можно и другие попробовать, но тут я не советчик.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от juriskr (ok) on 09-Мрт-11, 15:43
	сделайте "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" и попробуйте повторите ресинк. думаю все будет хорошо. >> Если честно, то не особо понимаю связь с 64бит системами ? > Ну как непонятно, написал выше, что с 32-битами такого не происходит, т.е. > все тихо и спокойно. > А тут, как только переехал на 64-битку - к чему эти коллтрейсы, > что они означают - аномалию работы в системе? > PS. Конечно, дело не в самих 64 битах, а их исполнении в > конкретной ОС - CentOS/64. > Стабильная "недовыпечка" качества 64-битового ядра, имхо - разве не так?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от chukcha2 (ok) on 09-Мрт-11, 16:12
	> сделайте "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" и попробуйте повторите ресинк. > думаю все будет хорошо. juriskr: Ок, допустим, все это сделаю и на какое-то время все "будет хорошо". Но меня беспокоит эти возникшие CallTrace - ведь неспроста они появились, причем на голом Центосе, на котором, кроме апдейта, еще не было ничего установлено? Значит, тому была веская причина. Какая? Какова гарантия, что они не повторятся? А что будет с системой, когда на нее еще навешается мускул, пхп, апач, нжинкс и т.д.? В-общем, одолевают сомнения в целесообразности перехода на 64-битовый Центос ввиду обнаруженных сообщений и предыдущего негативного опыта. Ведь по своему поведению и надежности веб-сервер должен быть, как и жена Цезаря, вне подозрений :) PS. Сорри, но другие ОС не рассматриваю ввиду многолетней привычки работать исключительно на CentOS. Ну разве что можно поглядеть на Scientific, но кто знает, отличаются ли он в лучшую сторону.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от juriskr (ok) on 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, но кто знает, отличаются ли > он в лучшую сторону.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от chukcha2 (ok) on 09-Мрт-11, 17:27
	> Не хвастобства ради: Ну, 295 дней конечно, хороший показатель :) У меня Xeon тоже по несколько месяцев работает, но когда выполняю минорный апдейт, все-таки ребутаюсь, для спокойствия ;) > В данном случае однозначно видно что процесс не повис а ожидает окончания синхронизации мд2. Тогда подскажите, плиз, по какой причине могла возникнуть надобность в возникшей синхронизации? Ведь сервер включен под UPS, никакой прикладной софт еще не установлен - и вдруг на тебе! Не говорит ли это опять-таки о погрешностях в реализации 64-битового ядра Центоса?
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от juriskr (ok) on 09-Мрт-11, 17:46
	Как вы догадываетесь на вопрос насчет синхронизации я ответить не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего. Я думаю с 64 битами это никак не связано. >> Не хвастобства ради: > Ну, 295 дней конечно, хороший показатель :) > У меня Xeon тоже по несколько месяцев работает, но когда выполняю минорный > апдейт, все-таки ребутаюсь, для спокойствия ;) >> В данном случае однозначно видно что процесс не повис а ожидает окончания синхронизации мд2. > Тогда подскажите, плиз, по какой причине могла возникнуть надобность в возникшей синхронизации? > Ведь сервер включен под UPS, никакой прикладной софт еще не установлен - > и вдруг на тебе! > Не говорит ли это опять-таки о погрешностях в реализации 64-битового ядра Центоса?
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от chukcha2 (ok) on 09-Мрт-11, 17:51
	> не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего. Это не проблема :) Что именно нужно сообщить? Или, если интересно, могу шелл дать :D
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от juriskr (ok) on 10-Мрт-11, 10:40
	>> не смогу поскольку не знаю ничего насчет среди, сборки дисков и прочего. > Это не проблема :) Что именно нужно сообщить? > Или, если интересно, могу шелл дать :D Спасибо за преджение, но думаю откажус. Но я уверен что с 64 битами ето не связано.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору

11. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
Сообщение от alex (??) on 10-Мрт-11, 16:32
Это "проблема" есть в 64 битной CentOS. Она зачем-то регулярно синхронизирует софтовые RAID массивы. Было тоже самое на CentOS 5.5 x86-64. После перевода системы на Debian 6 x86-64 (софтовый райд не трогался, так как squeeze его нормально подхватывает при установке системы) такой проблемы больше не наблюдается.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


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


	13. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от chukcha2 (ok) on 10-Мрт-11, 17:30
	> Она зачем-то регулярно синхронизирует софтовые RAID массивы Знать бы еще зачем. Может, это и хорошо как раз, но тогда варнинги следовало бы сделать более приятными, или убрать их по дефолту вообще. В-общем, из-за этой неясной ситуации установил Scientific Linux 6.0, пока щупаю, посмотрим, что он споёт.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору

14. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
Сообщение от Andrey Mitrofanov on 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 Требуйте в баг-трекерах своих сентосо-рэдхотов.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	15. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от Andrey Mitrofanov on 10-Мрт-11, 18:51
	> Требуйте в баг-трекерах своих сентосо-рэдхотов. Бонус! google:9744197c3d7b329590c2be33ad7b17409bd798fe google:9744197c3d7b329590c2be33ad7b17409bd798fe centos
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	16. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от chukcha2 (ok) on 12-Мрт-11, 04:05
	Andrey Mitrofanov: Что вы хотели своими репликами сказать, непонятно. Причем тут Дебиан, бонусы.... речь-то шла о Центосе.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	17. "CentOS, тягостный выбор: 64 или 32 бита?"	+/–
	Сообщение от Hammer (ok) on 29-Мрт-11, 19:54
	> Andrey Mitrofanov: > Что вы хотели своими репликами сказать, непонятно. > Причем тут Дебиан, бонусы.... речь-то шла о Центосе. http://www.google.ru/search?sourceid=chrome&ie=UTF-8&q=97441...
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору