Владельцам 3.8.6: не поставили патч - потеряли форум!

Файловый Архив

  • Неограниченное количество категорий и суб-категорий
  • Настройки прав доступа по группам
  • Настройки прав доступа по каждой категории
  • Предпросмотр медиа файлов: FLV, IFLV, F4A, F4V, MP4, MP3, MOV и других...
  • Мультизагрузка файлов - SWFUploader
  • Добавление файлов с сервера
Подробности и история обновлений продукта в этой теме
Loading

Go Back   форум vBSupport.org > > >
Register Изображения Меню vBsupport Files Manager Аллея Звёзд Реклама на форуме Search Today's Posts Mark Forums Read
  • Мемберка
  • Администраторам
  • Premoderation
  • For English speaking users
  • Изменения в правах
  • Каталог Фрилансеров
Пароли на скачивание файлов в Member Area меняются автоматически каждый день
Если вам нужно скачать какой то скрипт, за паролем ко мне в ЛС
привет какирам kerk
Ещё раз обращаем Ваше внимание: всё, что Вы скачиваете и устанавливаете на свой форум, Вы устанавливаете исключительно на свой страх и риск.
Сообщество vBSupport'а физически не в состоянии проверять все стили, хаки и нули, выкладываемые пользователями.
Помните: безопасность Вашего проекта - Ваша забота.
Убедительная просьба: при обнаружении уязвимостей или сомнительных кодов обязательно отписывайтесь в теме хака/стиля
Спасибо за понимание
На форуме введена премодерация ВСЕХ новых пользователей

Почта с временных сервисов, типа mailinator.com, gawab.com и/или прочих, которые предоставляют временный почтовый ящик без регистрации и/или почтовый ящик для рассылки спама, отслеживается и блокируется, а так же заносится в спам-блок форума, аккаунты удаляются
for English speaking users:
You may be surprised with restriction of access to the attachments of the forum. The reason is the recent change in vbsupport.org strategy:

- users with reputation < 10 belong to "simple_users" users' group
- if your reputation > 10 then administrator (kerk, Luvilla) can decide to move you into an "improved" group, but only manually

Main idea is to increase motivation of community members to share their ideas and willingness to support to each other. You may write an article for the subject where you are good enough, you may answer questions, you may share vbulletin.com/org content with vbsupport.org users, receiving "thanks" equal your reputation points. We should not only consume, we should produce something.

- you may:
* increase your reputation (doing something useful for another members of community) and being improved
* purchase temporary access to the improved category:
10 $ for 3 months. - this group can download attachments, reputation/posts do not matter.
20 $ for 3 months. - this group can download attachments, reputation/posts do not matter + adds eliminated + Inbox capacity increased + files manager increased permissions.

Please contact kerk or Luvilla regarding payments.

Important!:
- if your reputation will become less then 0, you will be moved into "simple_users" users' group automatically.*
*for temporary groups (pre-paid for 3 months) reputation/posts do not matter.
Не можете скачать вложение?
Изменения в правах групп пользователей
внимательно читаем эту и эту темы
Короткая версия - тут
Уважаемые пользователи!

На форуме открыт новый раздел "Каталог фрилансеров"

и отдельный раздел для платных заказов "Куплю/Закажу"

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

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

Маленькая предыстория. Имею 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. Результата не дало.

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


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

С уважением.
 
Bot
Yandex Bot Yandex Bot is online now
 
Join Date: 05.05.2005
Реклама на форуме А что у нас тут интересного? =)
Old  
Luvilla
Блондинка с электро......
 
Luvilla's Avatar
Default 0

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

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

других проблем с индексами что-то не могу вспомнить...
 
Old  
anemak
Простоузер
Default 0

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

Вот к примеру индексы одного из форумов, таблица 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
 
Old  
Luvilla
Блондинка с электро......
 
Luvilla's Avatar
Default 0

Quote:
Originally Posted by anemak View Post
Штатную проверку запускал, об этом уже упоминалось.
да, я прочла
поэтому и написала, что штатно вобла справляется - в смысле, что если проблема была с этим, то после проведения обслуживания проблема должна исчезнуть

Quote:
Originally Posted by anemak View Post
Вот к примеру индексы
лучше б скрином) читать тяжело
некоторые двоятся...
а userid - так вообще трижды, причём два раза - какие-то обломки... нет?

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

 
Old  
anemak
Простоузер
Default 0



Это с 5 столбика сместились userid, скрином и правда понятнее ...
 
Old  
Luvilla
Блондинка с электро......
 
Luvilla's Avatar
Default 0

на вид - всё нормально и соответствует штатной структуре таблицы
 
Old  
mindframe
Специалист
 
mindframe's Avatar
Default 0

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

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
....
 
Old  
Luvilla
Блондинка с электро......
 
Luvilla's Avatar
Default 0

Quote:
Originally Posted by anemak View Post
Насчет InnoDb - я сменил движки таблиц согласно структуре которую предполагали разработчики.
разработчиками чего? Майсиквела?
у воблы (конкретно 4.2) строгое указание таблиц есть для таблиц поиска, searchcore_text и searchgroup_text, и это как раз MyISAM
ну и таблицы сессий - отдельно указываются
остальные таблицы создаются, как скажет майсиквел, для новых это InnoDB

Quote:
Originally Posted by anemak View Post
Смущает почему пишет "Total fragmented tables: 709"
это суммарно для трёх форумов, надо понимать...
то есть, фрагментирована практически каждая таблица
а что показывается в ПМА, в колонке "фрагментировано"?

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

спорный же и вопрос относительно производительности.. есть мнение, что MyISAM на чтение работает быстрее, чем InnoDB
 
Old  
mindframe
Специалист
 
mindframe's Avatar
Default 1

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

Tags
apache, mysql, nginx, администрирование, сервер

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT +4. The time now is 06:42 PM.


Powered by vBulletin® Version Random
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.