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

На экране консоли вот такая хрень - 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 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 x86 + kernel-pae?

> CentOS x86 + kernel-pae?
Да, это когда стоял 32-битный.

Сейчас, на 64, штатное 2.6.18-194.32.1.el5

Да просто с программный рейд гавно какоето сыпет, не критичное. Думаю проблемы с железом у вас и от дистрибутива мало зависит.
Недавно ставил 64-битную федору (да да именно федору, якобы глюкаваю, падучую и т.д.) Ну дак вот, железка на Xeon - 8 ядер, Ram - 12гб, ФС - 12ТБ, правда рейд не программный, а человеческий :) - контроллер стоит. Ядро 2.6.33.3-85.x86_64. Работает вроде без сбоев и ошибок, правда apache там используется редко, пару посещений за день, так что не могу ничего про его падучесть сказать.

> Что скажут гуру?

Ты купил говно, а теперь решаешь, какие наклеечки могут это исправить.

>> Думаю проблемы с железом у вас и от дистрибутива мало зависит.

Я же описал в самом начале, что при использовании 64 бит даже на Ксеоне,т.е. Enterprise, были проблемы.
И на этой Интелке они тоже возникли, только в другом виде.

А вот 32 куда ни поставь - везде все нормально работает. Значит, железо ни при чем.

Господа гуру (специалист по гавну unanimous к ним вряд ли относится), я кончено, уважаю ваше мнение, но сдается мне, что в данном случае косяк все-таки в 64-битном ядре Центоса.

Если я не прав - агрументы, пожалуйста.

Аргументов нету, значит, железо правильное :)

А то ишь, на кого замахнулись - на саму Intel! :-D

Вообще, сравнение 32 vs 64, на мой взгляд, очень сильно зависит от дистриба. В каких-то дистрах больше внимания уделяют одной архитектуре, в каких-то - другой.

На моем собственном опыте на 64-битных системах проблем было в среднем меньше (в том числе и зависящих от железа).

А в конкретно вашем случае я совершенно не вижу причин не остановиться на проверенном и заведомо работающим 32-битном варианте: если всё работает, зачем что-то менять? Да, разница 32 vs 64 по производительности имеется, но кто сказал что 64 бита в вашем конкретном случае будет заметно быстрее, если будет вообще?

Аргументов нету, значит, железо правильное :)

А то ишь, на кого замахнулись - на саму Intel! :-D

У Intel внезапно стали получаться хорошие материнки? Кто тебе сказал такую глупость? :)

> (начало пропускаю)

Зря.

Для выкладывания логов используй сайты вроде pastebin.ca

И осиль таки gentoo.

>> У Intel внезапно стали получаться хорошие материнки? Кто тебе сказал такую глупость? :)
Разве? Неужто от AsRock или там Gigabyte они лучше? :)

Для выкладывания логов используй сайты вроде pastebin.ca

Они имеют обыкновение там исчезать, а мне хочется иногда перечитывать полезные заметки.
Лучше бы администрация ЛОРа осилила приатачивание логов.

И осиль таки gentoo.

Гы! :-D А ... зачем? Делать за кого-то дурную работу по компиле?
(ну, щас понесется :))

У меня 64-битный CentOS, программный raid 1, ядро stable от openvz (это в принципе не важно, даже наоборот должно быть потенциально меньше стабильности). Никаких проблем, высокие аптаймы, нагрузка. Бывают баги, kernel panic, но это сугубо openvz дела - обходятся, фиксятся.

>> Бывают баги, kernel panic,

Паник на удаленном серваке - прямая дорога ему фтопку.
На веб-хостингах такое не допускается в принципе, поскольку аптайм ниже 99,9% косит весь веб-бизнес под корень.

>Паник на удаленном серваке - прямая дорога ему фтопку.

KVM.

На веб-хостингах такое не допускается в принципе, поскольку аптайм ниже 99,9% косит весь веб-бизнес под корень.

Ну я ж не про продакшн. А тест на то и нужен, чтоб все потенциальные kernel panic найти и пофиксить до запуска в боевой режим. У меня web-сервер 3 месяца тестится.. 99,9% - это 8,76 минуты оффлайна в год. Такого трудно достичь. Даже если сервера в HA, даже если с датацентр типо Tier4 (что дорого) - всё равно где-нибудь ddos польётся, хотя бы на соседей по шкафу - уже будет офф, пока трафик не остановят.

Неужто 8,76 минуты? :)
Признаться, не пересчитывал проценты на минуты, просто когда арендовал дедики у хостеров, они мне гарантировали такой процент аптайма, само число мне нравилось, ну и ладушки ;)

Mar 9 04:22:02 server kernel: INFO: task md0_resync:4273 blocked for more than 120 seconds.

Такое бывает, если сам RAID-массив или входящие в него диски чем-то очень сильно нагрузить во время ресинхронизации. Если при этом синхронизация не останавливается совсем, то ничего страшного не должно случиться.

Ещё, чисто на всякий случай, можно посмотреть SMART жёстких дисков.

mironov_ivan -

Понятно. Как раз сервак стоял всю ночь абсолютно ничем не нагруженный, отдыхая после моих шаманств, так что чего его вдруг понесло синкаться, непонятно.
Винты совершенно новые, в Смарте все идеально, так что фигзнает.

Хотя уже перешел на SL6, все равно спасибо за полезные соображения.

>> 99,9% - это 8,76 минуты оффлайна в год.

Хех! :) Пересчитал - ну и где же ваши 8,76 минуты?
На самом деле их 526, т.е. около 9 часов в год!

Ввели меня в заблуждение, уважаемый Aman :-P

>Неужто 8,76 минуты?

Школьная математика, но сам ошибся )) 99,9% на год - 525,6 минут оффлайна, 8,76 часов. Но всё-равно таких очень мало ). Основная проблема - ddos.

они мне гарантировали такой процент аптайма

Ну а что вы от них хотели. Есть 99,999% аптайм (5,256 минуты простоя). Но это будет очень серьёзный телеком. Сказанное - для общедоступного веба.

Ответили одновременно, секунда в секунду :))