[Проблема] Во что упирается производительность vBulletin - проблемы (MySQL, Apache, Nginx, серверное железо)

05-04-2013, 12:13 PM

Здравствуйте,

Маленькая предыстория. Имею 3 небольших форума на vBSuite 4.2.0, суммарная посещаемость проектов ~5000 ч/сутки, суммарное количество тем ~150тыс., сообщений ~3млн. Администрирую форумы сам, обслуживаю сервер тоже. Использую архитектуру Debian 6 + Nginx(front-end) + Apache(back-end) + MySQL 5.1. До недавнего времени размещался на VDS с RAM 512mb, производительность упиралась в количество RAM используемой MySQL, поэтому все решалось настройками my.cnf. В пики посещаемости форум начинал слегка подтормаживать (загрузка страниц поднималась до 3-4 сек) но было терпимо, а вот узким местом стала генерация карты сайта vBSEO Sitemap, во время нее сервер уходил в своп и переставал отдавать форумы примерно на час. Хоть это и происходило редко, но крайне действовало на нервы, с распределением RAM бороться уже надоело. Любое обновление базы данных, для модулей или просто чистка - вызывало тормоза, иногда оборачивалось падением. Что ж, пора апгрейдиться.

Чтобы не заморачиваться с дальнейшим масштабированием проектов, нужно было в первую очередь отказаться от виртуальных серверов, потому арендовал новый сервер помощнее:

Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
RAM 32GB
HDD 2x3TB SATA 6 Gb/s 7200 rpm (Software-RAID 1)

Архитектуру решил оставить ту же, настройки Apache (prefork) и Nginx взял со старого VDS:

Code:

Timeout 300
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>

Code:

user www-data;
worker_processes			1;

error_log				/var/log/nginx/error.log;
pid					/var/run/nginx.pid;

events {
	worker_connections		8192;
	use epoll;
}

http {
	access_log						/var/log/nginx/access_log combined;
	include							/etc/nginx/mime.types;
	default_type					application/octet-stream;
	server_tokens					off;
	reset_timedout_connection		on;
	client_header_timeout			10m;
	client_body_timeout				10m;
	send_timeout					10m;
	connection_pool_size			256;
	client_header_buffer_size		8k; 
	large_client_header_buffers		100 8k;
	request_pool_size				4k;
	client_max_body_size			1024m;

	proxy_buffering					on;
	proxy_buffers					512 8k;
	proxy_buffer_size				8k;
	proxy_read_timeout				180;
	proxy_connect_timeout			300;
	proxy_send_timeout				600;
	proxy_ignore_client_abort		off;
	proxy_intercept_errors			off;

	gzip							on;
	gzip_comp_level					4;
	gzip_disable					"MSIE [1-6]\.";
	gzip_min_length					1100;
	gzip_buffers					4 8k;
	gzip_types						text/plain text/css text/xml application/x-javascript;

	output_buffers					4 32k;
	postpone_output					1460;
	sendfile						on;
	tcp_nopush						on;
	tcp_nodelay						on;

	keepalive_timeout				300 300;
	ignore_invalid_headers			on;

	include							/etc/nginx/conf.d/*.conf;
	include							/etc/nginx/sites-enabled/*;
}

При переносе проектов встретилась первая проблема: у двух форумов была база на InnoDB, у одного на MyISAM. Решено было за большинство, поэтому MyISAM конвертнул в InnoDB. Итого у всех форумов структура такая:

Структура таблиц

Честно сказать, не был обременен вопросом, что из этого быстрее, как уже писал, взял за большинство, и сделал InnoBD.

Сутки после установки погонял базу на дефолтных конфигах MySQL. После понемногу начал вносить изменения. Итого спустя неделю конфиг такой (некоторые параметры преднамеренно завысил, посмотреть на производительность БД, благо памяти пока много.):

Code:

[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

[mysqld]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

default-character-set=cp1251
character-set-server=cp1251
collation-server=cp1251_general_ci
init-connect=SET NAMES cp1251
skip-character-set-client-handshake

table_cache = 8192
table_open_cache = 8192

tmp_table_size = 2G
max_heap_table_size = 2G

query_cache_size = 128M
query_cache_limit = 512M

log_slow_queries	= /var/log/mysql/mysql-slow.log
long_query_time = 2

sort_buffer_size = 2G
key_buffer_size = 2G

skip-locking
max_allowed_packet = 1M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8

thread_concurrency = 8
innodb_buffer_pool_size = 16G

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

Форумы грузятся быстро, средняя нагрузка MySQL на CPU 0,8%, в пике до 5%, объем потребляемой RAM 5Гб.

Дальше занялся обновлением счетчиков (Обслуживание-Основные инструменты обновления). Вот тут я и встретился со своей главной проблемой. Например функции "Перестроить информацию о темах" или "Перестроить похожие темы" работают очень медленно, при этом нагрузка на цп не поднимается выше 10%, потребление памяти увеличивается примерно на 1Гб. На локальном тестовом сервере это проходило гораздо быстрее, на дефолтных конфигах то! Судя по всему проблема в базе данных. Вот отчет PMA за текущие сутки:

Состояние MySQL

Не понравились значения:

Handler_read_rnd 193 k Количество запросов, на чтение строки, основанных на ее позиции. Большое значение переменной может быть обусловлено частым выполнением запросов использующих сортировку результата, выполнением большого числа запросов требующих полного сканирования таблиц, наличием объединений не использующих индексы надлежащим образом.
Handler_read_rnd_next 5,743 k Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, при частом сканировании таблиц. Обычно это означает, что таблицы не проиндексированы надлежащим образом или запросы не используют преимущества индексов.

Created_tmp_disk_tables 187 Количество временных таблиц, автоматически созданных сервером на диске, во время выполнения SQL-выражений. Если значение Created_tmp_disk_tables велико, следует увеличить значение переменной tmp_table_size, чтобы временные таблицы располагались в памяти, а не на жестком диске.

Key_writes 771 k Количество физических операций записи блока индексов на диск.

Opened_tables 3,415 Общее количество открывавшихся таблиц. При большом значении переменной рекомендуется увеличить размер кеша таблиц (table_cache).

Судя из написанного - что то с индексами таблиц. Запустил mysqlcheck -o --all-databases; сделал "Исправление уникальных индексов" средствами vB. Результата не дало.

Что можно еще сделать в данной ситуации? Почему сервер БД не использует больше системных ресурсов? Что делать с индексами?

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

С уважением.

05-04-2013, 02:22 PM

Quote:

Originally Posted by anemak

Судя из написанного - что то с индексами таблиц. Запустил mysqlcheck -o --all-databases; сделал "Исправление уникальных индексов" средствами vB. Результата не дало.

Что можно еще сделать в данной ситуации? Почему сервер БД не использует больше системных ресурсов? Что делать с индексами?

интересный вопрос...
для начала, хорошо бы выяснить, что с ними нЕ так
варианты:
- Индексы могут отсутствовать. В этом случае штатная операция по исправлению из админки вполне успешно справляется с проблемой
- Индексы могут быть "повреждены". В этом случае, аналогично первому, штатно вобла справляется
- Индексы могут быть "заблокированы". Такое почему-то частенько возникает при переносе на другой сервер.
Как проверить?
ПМА, открыть любую проблемную/подозрительную таблицу, у Вас в первую очередь смотреть надо таблицы пост и тред - структура, и смотрим внизу, где индексы, в пункте "комментарий" - а не указано ли там disabled?
если да (выключены/заблокированы индексы) -
решение: выполняем запрос
ALTER TABLE 'имя_таблицы' ENABLE KEYS

других проблем с индексами что-то не могу вспомнить...

05-04-2013, 02:32 PM

Штатную проверку запускал, об этом уже упоминалось.

Вот к примеру индексы одного из форумов, таблица post:

Code:

Действие	Имя индекса	Тип	Уникальный	Упакован	Поле	Уникальных элементов	Сравнение	Null	Комментарий
		PRIMARY	BTREE	Да	Нет	postid	2335662	A		
		userid	BTREE	Нет	Нет	userid	467132	A		
		threadid	BTREE	Нет	Нет	threadid	467132	A		
		userid	2335662	A	
		threadid_visible_dateline	BTREE	Нет	Нет	threadid	333666	A		
		visible	333666	A	
		dateline	2335662	A	
		userid	2335662	A	
		postid	2335662	A	
		dateline	BTREE	Нет	Нет	dateline	2335662	A		
		ipaddress	BTREE	Нет	Нет	ipaddress	356243	A		
		user_date	BTREE	Нет	Нет	userid	467132	A		
dateline	2335662	A

Code:

Используемое пространство
Тип	Использование
Данные	444.9	МБ
Индекс	371.8	МБ
Всего	816.8	МБ

Статистика строк
Характеристика	Значение
Формат	Compact
Сравнение	cp1251_general_ci
Следующий Autoindex	2,065,531
Создание	Май 03 2013 г., 12:23

05-04-2013, 02:50 PM

Quote:

Originally Posted by anemak

Штатную проверку запускал, об этом уже упоминалось.

да, я прочла
поэтому и написала, что штатно вобла справляется - в смысле, что если проблема была с этим, то после проведения обслуживания проблема должна исчезнуть

Quote:

Originally Posted by anemak

Вот к примеру индексы

лучше б скрином) читать тяжело
некоторые двоятся...
а userid - так вообще трижды, причём два раза - какие-то обломки... нет?

скрин, голая 4.2

05-04-2013, 03:00 PM

Это с 5 столбика сместились userid, скрином и правда понятнее ...

05-04-2013, 03:04 PM

на вид - всё нормально и соответствует штатной структуре таблицы

05-04-2013, 03:10 PM

mysqltuner попробуйте, я сейчас особо конфиги не читал, но тоже есть сомнения в их оптимальности.
http://habrahabr.ru/post/108418/
Как базовый пример подойдёт.
Я лично на своих серверах давно уже отказался от апача в пользу fpm, всё работает стабильно, брат жив.
В скором времени планирую переезд на MariaDB, а насчёт InnoDB вы правы, но не поголовно надо все таблицы конвертить.

05-04-2013, 03:37 PM

mysqltuner

тут все гуд вроде, ругается на некоторые завышенные параметры (при 150 одновременных коннектах, будет потребляться 300Гб памяти), это нормально, я их преднамеренно завысил на некоторое время ...

Смущает почему пишет "Total fragmented tables: 709" ведь все они оптимизировались, и должны быть дефрагментированы. с "Query cache efficiency: 2.1% (20K cached / 1M selects)" тоже не понятно, сколько бы парамерт не увеличивал, ничего не меняется.

Насчет InnoDb - я сменил движки таблиц согласно структуре которую предполагали разработчики. Показалось странным что одна из баз была на MyISAM, возможно это появилось в какой то версии vB

Code:

....
	if ($memory) 
	{ // Use Memory if possible, and allowed
		return 'MEMORY';
	}
	else if ($innodb)
	{ // Otherise try Innodb
		return 'InnoDB';
	}
	return 'MyISAM'; // Otherwise default to MyISAM.
}

// Choose Engine for Session Tables.
function get_session_engine($db)
{
	return get_engine($db, true);
}

// Determines which mysql engine to use for high concurrency tables
// Will use InnoDB if its available, otherwise MyISAM
....

05-04-2013, 04:31 PM

Quote:

Originally Posted by anemak

Насчет InnoDb - я сменил движки таблиц согласно структуре которую предполагали разработчики.

разработчиками чего? Майсиквела?
у воблы (конкретно 4.2) строгое указание таблиц есть для таблиц поиска, searchcore_text и searchgroup_text, и это как раз MyISAM
ну и таблицы сессий - отдельно указываются
остальные таблицы создаются, как скажет майсиквел, для новых это InnoDB

Quote:

Originally Posted by anemak

Смущает почему пишет "Total fragmented tables: 709"

это суммарно для трёх форумов, надо понимать...
то есть, фрагментирована практически каждая таблица
а что показывается в ПМА, в колонке "фрагментировано"?

===
по поводу InnoDB вообще вопрос спорный...
если таблица "крашится", то MyISAM чинится относительно без проблем, при каких-то фатальных сбоях таблицу можно вытащить
если колом встанет InnoDB - с ней никак, только из бэкапа вынимать (имею зубодробильный опыт восстановления одного форума, когда таблицы пришлось собирать буквально по кускам... сейчас этот форум работает, таблицы в MyISAM, проблем не наблюдается)

спорный же и вопрос относительно производительности.. есть мнение, что MyISAM на чтение работает быстрее, чем InnoDB

05-04-2013, 04:52 PM

Quote:

Originally Posted by Luvilla

порный же и вопрос относительно производительности.. есть мнение, что MyISAM на чтение работает быстрее, чем InnoDB

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