LINUX.ORG.RU

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


0

1

О преимуществах 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

и т.д.

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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


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

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

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

chukcha ★★★ ()
Ответ на: комментарий от LongLiveUbuntu

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

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

simak ()
Ответ на: комментарий от chukcha

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

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

unanimous ★★★★★ ()
Ответ на: комментарий от simak

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

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

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

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

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

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

chukcha ★★★ ()

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

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

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

aix27249 ()
Ответ на: комментарий от chukcha

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

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

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

aix27249 ()
Ответ на: комментарий от chukcha

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

Зря.

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

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

ky-san ()
Ответ на: комментарий от aix27249

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

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

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


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

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

chukcha ★★★ ()

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

Aman ()
Ответ на: комментарий от Aman

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

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

KVM.

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

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

Aman ()
Ответ на: комментарий от Aman

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

mironov_ivan -

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

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

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

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

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

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

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

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

Aman ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.