Опыт одного IT`шника

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

Но в данной статье я опишу свою двух часовую эпопею по больбе с модулем “производительность” в Bitrix, процетирую часть отчета, немного переделанного:

Тестирование производилось на  двух серверах назовем их сервер 1 и сервер 2. Сервер 1 довольно загруженный сервер, по конфигу это Q9550, 8 гигов памяти, и 2 винта WD Green в raid 1, при этом iostat около 10, а средняя нагрузка 5-6 la, конфиг второго сервера представлен ниже по тексту

На сервере 1 размещаются клиенты и есть определенная нагрузка, на 2
на момент тестирования не было клиентов, по конфигурации сервер 2

2 процессора Xeon E5504

8 гигабайт памяти DDR3

2 серверных винчествера от Seagete по 500 гигабайт объеденных в RAID 1

Смотрели значение выдаваемые модулем производительность а так же скорость открытия

страниц.

На сервере 1 мы предположили что результаты тестов могут быть небольшими из-за нагрузки системы или каких то узких мест, сайт окрывался довольно шустро, при этом модуль производительность не показывал более 3-4 едениц, для сравнения на vmware которую дает битрикс около 30 едениц, среднее время открытия страниц 0.4 – 0.5 секунд. Далее мы произвели тестирование на пустом сервере,  замечу что на сервере стоит 2 мощных процессора и в любоймомент времени было доступно как минимум 7 свободных ядер, каждое ядро работает на частоте большей чем частота указанная на виртуально машине (2.83 против 2.2 гигагерц), дисковая подсистема не нагружена, и соответственно остальные параметры были выше,  как не странно выдаваемые значения в модуле производительность не поднялись =(, хотя зачему что страницы начали загружатся еще бустрее. Тестовую виртуальную машину можно скачать с сайта Bitrix, после сравнения настроек мы обнаружили что в качестве системы ускорения php используется Zend Server, у нас же EAccelerator, в свое время я тестировал производительность серверов с разными ускорителями PHP и приняли решение использовать EAccelerator, да и привычней он как то.

Из всего сказаного можно сделать вывод что либо Bitrix продвигают продукты от Zend, либо модуль производительности написан крайне криво. Но в любом случае обьяснять технически не очень грамотному человеку почему у нас на пустом сервере производительность 2-4 еденицы, а на виртуалке которую он скачал 30 довольно сложное занятие, в глубине души я надеюсь что данная ситуация скоро исправится.

Хотелось бы расказать об очередной проблеме которая заняла у меня пол дня.

Купили сервер:

Платформа: SR1630BC

Процессоры: 2 x E5504

Память: 2 X DDR3 4Gb PC-10600

два серверных винта Seagete по 500 гигов каждый

Фото самого сервер представленно выше, сервер собрали, включили в сеть, нажимаем на power и ноль реакции, т.е. кулера не запускаются.

Прочитав инструкцию поняли что память поставили не правильно, впринципе логично поставить память в черные слоты, которые самые близкие к процессору, но как оказалось память нужно ставить в синие слоты. Сервер разобрали изменили, результат тот же.

Из признаков жизни, это горящий индикатор warning на передней панели сервера (на рисунке уже запущенный сервер)

и мигающий индикатор на блоке питания

Но все наши старания не помолги запустить, сервер. не помогли запустить сервер. На следующий день повезли сервер в ремонт, у гарантийного отдела он запустился через 5 минут, как они сказали нужно было только подождать при первом запуске… сервер не отдавали еще час говорили что перепрошивают BIOS, незнаю верить нет.

На этом особености данного сервера не кончелись, в BIOS когда меняется тип SATA контролера (NEGATIVE/AHCI/RAID) извенеия на вкладке Boot появляются только после перезагрузки, на то что бы это обнаружить опять таки ушло минут 20. KVM под рукой не было так что скринов к сожалению приложить не могу.

Из инетересного еще понравился вывод htop:

На ubuntu server 9.10 в данный момент последний релиз MySQL версии 5.1.31-1ubuntu2.

В нем есть небольшой БАГ, описан он тут http://bugs.mysql.com/bug.php?id=42400, проявляется он на UMI.CMS, сама CMS ставится без каких либо ошибок, но при редактировании страниц, появляется ошибка

#2013 – Lost connection to MySQL server during query

При этом CMS продолжает работать в логах сервера повляется следующее сообщение:

100211 16:46:39  InnoDB: Assertion failure in thread 140202732034384 in file handler/ha_innodb.cc line 3454
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
100211 16:46:39 – mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=33554432
read_buffer_size=131072
max_used_connections=40
max_threads=400
threads_connected=27
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 907230 K
bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

thd: 0×35d98a0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0×7f837e0a10d0 thread_stack 0×80000
/usr/sbin/mysqld(my_print_stacktrace+0×29) [0x8b4f89]
/usr/sbin/mysqld(handle_segfault+0×383) [0x5f8f03]
/lib/libpthread.so.0 [0x7f8389dc9080]
/lib/libc.so.6(gsignal+0×35) [0x7f8388857fb5]
/lib/libc.so.6(abort+0×183) [0x7f8388859bc3]
/usr/sbin/mysqld(ha_innobase::innobase_get_int_col_max_value(Field const*)+0×2d) [0x77909d]
/usr/sbin/mysqld(ha_innobase::get_auto_increment(unsigned long long, unsigned long long, unsigned long long, unsigned long long*, unsigned long long*)+0×173) [0x77eec3]
/usr/sbin/mysqld(handler::update_auto_increment()+0×1fe) [0x6daebe]
/usr/sbin/mysqld(ha_innobase::write_row(unsigned char*)+0×3c8) [0x77d858]
/usr/sbin/mysqld(handler::ha_write_row(unsigned char*)+0×73) [0x6dde13]
/usr/sbin/mysqld(write_record(THD*, st_table*, st_copy_info*)+0×71) [0x6738d1]
/usr/sbin/mysqld(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool)+0×9c7) [0x677e77]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0×954) [0x6070e4]
/usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0×212) [0x60c092]
/usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xdcf) [0x60d57f]
/usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60dda8]
/usr/sbin/mysqld(handle_one_connection+0×226) [0x601426]
/lib/libpthread.so.0 [0x7f8389dc13ba]
/lib/libc.so.6(clone+0×6d) [0x7f838890afcd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort…
thd->query at 0×7f837018f7e0 is an invalid pointer
thd->thread_id=1512
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
100211 16:46:39 mysqld_safe Number of processes running now: 0
100211 16:46:39 mysqld_safe mysqld restarted

Что бы диагностировать эту ошибке достаточно в таблицу cms_backup UMI.CMS попробовать вставить любое значение.

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

MySQL самом собой стандартными средствами обновили, ошибка пропала, все работало отлично до первой перезагрузки сервера, пре загрузки сервер выдал сообщение:

Скрин сервера

при этом сам сервер не стартанул, пришлось загружатся в initramfs монтировать в ручную файловые системы, и выяснять причину, которая оказалось бонально, при обновлении MySQL обновиласть одна из системных библиотек и mountall возвращал warning из-за чего загрузка останавливалась. После полного обновления всей системы сервен нормально загрузился.

Столкнулся с интересной проблемой после устновки CMS Live Street выдавалась ошибка:

SQL Error: Unknown MySQL server host ‘test_ls’ (1) at /home/p/***/***/public_html/classes/modules/sys_database/Database.class.php line 67
Array ( [code] => 2005 [message] => Unknown MySQL server host 'test_ls' (1) [query] => mysql_connect() [context] => /home/p/***/***/public_html/classes/modules/sys_database/Database.class.php line 67 )

Что интересно раньше когда все настраивал все работало, собственно конфиг подключения к БД

return array(
'host' => 'localhost',
'port' => '3306',
'user' => 'test_ls',
'pass' => 'LWOkD/2J9',
'type' => 'mysql',
'dbname' => 'test_ls',
);

начал разбиратся, для подключения формируется строка и передается в класс

mysql://test_ls:LWOkD/2J9@localhost:3306/test_ls

т.е. если в пароле есть символ слеша то CMS перестает роботать. Отписался разработчикам, жду ответа возможно исправят