Тормоза на Улановке. Фряшники, сисадмины, программисты, нужна помощь специалистов!

Mac · 30 января, 2008

Товарищи! Отечество в опасности!

Обращаюсь ко всем, кто хоть как-то связан с администрированием веб-серверов и программированием с просьбой о помощи. Как вы все видите, уже не первый месяц вечером на Улановку зайти становится все сложнее из-за нагрузки на сервер. В чем причина. Давайте разберемся вместе!

Для начала опишу отброшенные гипотезы:

[*:d7149e892e]Загрузка канала. Возможной причиной тормозов могли быть забитые каналы, но в этом случае страницы генерировались штатно быстро, а загружались бы медленно (по частям). Это мы не наблюдаем, и слава богу.
[*:d7149e892e]Маломощность серверного "железа". Администратор форума Сибирьтелекома любезно предоставил нам конфигурацию "железа". Это действительно неслабая машина. Ее теоретически должно хватать для правильной работы веб-сервера с нашей нагрузкой (при правильной его настройке, конечно).

Основных гипотез две:

[*:d7149e892e]Ошибки и неоптимальный код движка.
Сисадмины Сибирьтелекома, на серверах которого физически находится трекер, придерживаются именно ее, полагая, что дело в самом форумном движке phpBB, который не является лучшим выбором для подобного проекта. Я, честно говоря, не совсем согласен с этим утверждением, аргументируя это тем фактом, что phpBB используется во всем мире и входит в тройку самых популярных форумных движков. Существует множество форумов с куда большей посещаемостью, которые не страдают такими пролемами. Также скажу, что перелопатил все русское сообщество phpbb в тщетных попытках найти ответ на свой вопрос. Всевозможные мелкие уловки и хаки для оптимизации уже установлены (# кэширование, использование динамических HEAP-таблиц для хранения сессий, ограничение количества сессий, включение/выключение сжатия gzip и пр.).
[*:d7149e892e]Неправильная (неоптимальная) настройка сервера.
Я сам склоняюсь к этому мнению. В администрировании веб-серверов я, к сожалению, не силен, потому опираюсь лишь на свои дилетантские знания и гугл. Поэтому прошу людей знающих подсказать возможные пути решения проблемы в этом направлении. Конфигурацию сервера (phpinfo) предоставлю, может она прольет свет на возможные причины тормозов.

К слову скажу, что недавно исправленная ошибка с загрузкой аватаров на сервер была связана именно с ошибкой в настройке веб-сервера - неправильно установленной директивой open_basedir в php.ini.

Прошу программистов помочь разобраться в первой теории, а системщиков - поработать во втором направлении. Уверен, вместе мы найдем причину и устраним ее!

График распределения нагрузки на сервер по времени суток выглядит примерно так:

Как видно из рисунка, максимальный пик попадает на промежуток с 18.00 вечера до 00.00. А минимальная нагрука приходится на 5-6 утра.

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

30 января, 2008

Топик был перенесен из форума Программирование в форум Работа трекера

Mac

Merlin · 31 января, 2008

а на сервере, кроме форума Улановки еще что-нить крутится?

неплохо было бы еще посмотреть результаты команды top во время максимальных загрузок..

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

mysqld, множество httpd или вообще что-нить совсем другое..

VampiRUS · 31 января, 2008

Мне кажется нужно копануть в сторону оптимизации sql запросов

dr_agon · 31 января, 2008

может скажу глупость - тормоза sql-запросов ликвидируются переиндексацией БД и ежедневным ребутом web-сервера, иногда просто админы мало уделяют внимание swap и ставят его на внешних дорожках накопителей - в таком случае своп забивается быстрее

btc · 31 января, 2008

а параметры сервера увидеть можно ? Какой софт и железо там стоит?

Вадимка · 31 января, 2008

ИМХО, 2-й вариант - сервер, в частности PHP, настроен криво. Об этом может говорить то, что сам сайт stbur.ru, открывается крайне медленно. Что делать: работать с админами.

Hedge · 31 января, 2008

btc

"ацтойное галимое железо стбура"
The world's best selling server just got better; the new ProLiant DL380 delivers on its history of design excellence with enterprise-class uptime and manageability, proven 2-way Intel Xeon performance, and 2U density for a variety of rack deployments and applications.
What's new
Introducing the HP ProLiant DL380 G4, now available with the latest Intel Xeon processors and new high performance models for convenient fully loaded configurations:
Performance
* Intel® Xeon™ processors with EM64T, 800 MHz FSB
* 400MHz DDR-2 Memory, 6 sockets, 12GB Max (Note: 6GB Max at launch - 2GB DIMM availability is expected in 4Q04)
* Ultra 320 Smart Array 6i w/transportable BBWC (128MB) option
* High Performance models
Management
* iLO shared network port
* SmartStart 7.1
Options
* (3) PCI-X Expansion Slots non-hot-plug standard, optional PCI-E or hot-plug PCI-X
* Optional improved duplex drive backplane
* Optional floppy drive
Design
* USB up-front
* Universal rails (fits square and round hole racks)
* Ambidextrous snap-on cable management arm and quick release levers provide fast access to server
Specs at a glance
DL 380G4
Processor Intel Xeon™ DP processor at 3.6 GHz/2MB standard (up to 2 supported), 800 MHz FSB
Standard memory 1 GB
Max memory 12 GB
Max internal drives 6 x SCSI, 8 x SAS
Form factor 2U
Ideal environment
Environments of all types and sizes
* The unmatched flexibility of the DL380 has made it the best selling server in the world - sold to businesses of all sizes for a vast array of applications.
* Large internal storage capacity for everything from web apps to databases
* Easily connected to storage networks and easily managed from wherever you are
Space-constrained corporate data centers and service providers
* The DL380 packs the storage, memory, and I/O you need into only 2U of rack space
* Ambidexterous cable management and a quick deploy rail solution make racking a snap
* Availability features like hot plug/redundant power, online spare memory, and hot plug/redundant fans keep environments up and running and users productive
Sophisticated SMB locations
* The DL380 is not just for enterprises. Small and medium businesses with rack environments that can benefit from remote server management or network backup should consider the DL380.
* Not ready for a rack environment? Consider the ProLiant ML370.

а вообще вот тема: stbur

CooDi · 31 января, 2008

Возможно, что php подключен к апачу как cgi а не как библиотека (хотя я сомневаюсь).

Mac · 31 января, 2008

Вот phpinfo()

Mac · 1 февраля, 2008

И тишина...

Вот тут конкретно с торрентпировского форума админ пишет:

небольшие советы по увеличению производительности
1. не допускать использования свопа
2. поставить какой-нибудь php-кеш, например APC (http://pecl.php.net/package/APC), используется на torrents.ru и torrents.net.ua, дает существенное увеличение производительности
3. включить в mysql query_cache ну и увеличить остальные буфера по вкусу
4. избавится от apache, освобождается куча памяти, которую можно отдать, например, mysql-у. torrents.net.ua сейчас работает на связке nginx + php-fastcgi

И вот выдержка из статьи по оптимизации сервера:

MySQL
Добавьте или измените следующие опции в my.cnf:
[*:dcdd874aa0]Отключите bin log
log-bin
[*:dcdd874aa0]Включите и увеличте размер query_cache
query_cache_limit = 2M   # по умолчанию было 1M
query_cache_size  = 64M  # по умолчанию было 0
query_cache_type  = 1
[*:dcdd874aa0]Увеличте table_cache
table_cache = 256 # по умолчанию было 64
[*:dcdd874aa0]Увеличте key_buffer
key_buffer_size = 64M # по умолчанию было 8M
[*:dcdd874aa0]Установите параметр max_connections так, чтобы он равнялся параметру MaxClients в настройках Apache

Источник.

В данный момент эти параметры у нас по дефолту:

query_alloc_block_size	8192
query_cache_limit	1048576
query_cache_min_res_unit	4096
query_cache_size	0
query_cache_type	ON
query_cache_wlock_invalidate	OFF
query_prealloc_size	8192

table_cache	64

key_buffer_size	8388600

max_connections	100

Системные переменные MySQL сервера:

Переменные сервера значения переменных
back_log 50
basedir /usr/
bdb_cache_size 8388600
bdb_home /var/lib/mysql/
bdb_log_buffer_size 32768
bdb_logdir
bdb_max_lock 10000
bdb_shared_data OFF
bdb_tmpdir /tmp/
binlog_cache_size 32768
bulk_insert_buffer_size 8388608
character_set_client cp1251
character_set_connection cp1251
character_set_database cp1251
character_set_results cp1251
character_set_server cp1251
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
collation_connection cp1251_swedish_ci
collation_database cp1251_general_ci
collation_server cp1251_general_ci
concurrent_insert ON
connect_timeout 5
datadir /var/lib/mysql/
date_format %Y-%m-%d
datetime_format %Y-%m-%d %H:%i:%s
default_week_format 0
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
expire_logs_days 0
flush OFF
flush_time 0
ft_boolean_syntax + -><()~*:""&|
ft_max_word_len 84
ft_min_word_len 4
ft_query_expansion_limit 20
ft_stopword_file (built-in)
group_concat_max_len 1024
have_archive NO
have_bdb YES
have_blackhole_engine NO
have_compress YES
have_crypt YES
have_csv NO
have_example_engine NO
have_geometry YES
have_innodb YES
have_isam YES
have_ndbcluster NO
have_openssl YES
have_query_cache YES
have_raid NO
have_rtree_keys YES
have_symlink YES
init_connect
init_file
init_slave
innodb_additional_mem_pool_size 1048576
innodb_autoextend_increment 8
innodb_buffer_pool_awe_mem_mb 0
innodb_buffer_pool_size 8388608
innodb_data_file_path ibdata1:10M:autoextend
innodb_data_home_dir
innodb_fast_shutdown ON
innodb_file_io_threads 4
innodb_file_per_table OFF
innodb_flush_log_at_trx_commit 1
innodb_flush_method
innodb_force_recovery 0
innodb_lock_wait_timeout 50
innodb_locks_unsafe_for_binlog OFF
innodb_log_arch_dir
innodb_log_archive OFF
innodb_log_buffer_size 1048576
innodb_log_file_size 5242880
innodb_log_files_in_group 2
innodb_log_group_home_dir ./
innodb_max_dirty_pages_pct 90
innodb_max_purge_lag 0
innodb_mirrored_log_groups 1
innodb_open_files 300
innodb_table_locks ON
innodb_thread_concurrency 8
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 8388600
key_cache_age_threshold 300
key_cache_block_size 1024
key_cache_division_limit 100
language /usr/share/mysql/english/
large_files_support ON
license GPL
local_infile ON
locked_in_memory OFF
log OFF
log_bin OFF
log_error
log_slave_updates OFF
log_slow_queries OFF
log_update OFF
log_warnings 1
long_query_time 10
low_priority_updates OFF
lower_case_file_system OFF
lower_case_table_names 0
max_allowed_packet 1048576
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connect_errors 10
max_connections 100
max_delayed_threads 20
max_error_count 64
max_heap_table_size 16777216
max_insert_delayed_threads 20
max_join_size 4294967295
max_length_for_sort_data 1024
max_relay_log_size 0
max_seeks_for_key 4294967295
max_sort_length 1024
max_tmp_tables 32
max_user_connections 0
max_write_lock_count 4294967295
myisam_data_pointer_size 4
myisam_max_extra_sort_file_size 2147483648
myisam_max_sort_file_size 2147483647
myisam_recover_options OFF
myisam_repair_threads 1
myisam_sort_buffer_size 8388608
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
new OFF
old_passwords ON
open_files_limit 1024
pid_file /var/run/mysqld/mysqld.pid
port 3306
preload_buffer_size 32768
protocol_version 10
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_min_res_unit 4096
query_cache_size 0
query_cache_type ON
query_cache_wlock_invalidate OFF
query_prealloc_size 8192
range_alloc_block_size 2048
read_buffer_size 131072
read_only OFF
read_rnd_buffer_size 262144
relay_log_purge ON
relay_log_space_limit 0
rpl_recovery_rank 0
secure_auth OFF
server_id 0
skip_external_locking ON
skip_networking OFF
skip_show_database OFF
slave_net_timeout 3600
slave_transaction_retries 0
slow_launch_time 2
socket /export/var/lib/mysql/mysql.sock
sort_buffer_size 2097144
sql_mode
storage_engine MyISAM
sql_notes ON
sql_warnings ON
sync_binlog 0
sync_replication 0
sync_replication_slave_id 0
sync_replication_timeout 0
sync_frm ON
system_time_zone IRKT
table_cache 64
table_type MyISAM
thread_cache_size 0
thread_stack 196608
time_format %H:%i:%s
time_zone SYSTEM
tmp_table_size 33554432
tmpdir
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
tx_isolation REPEATABLE-READ
version 4.1.12
version_bdb Sleepycat Software: Berkeley DB 4.1.24: (May 13, 2005)
version_comment Source distribution
version_compile_machine i686
version_compile_os redhat-linux-gnu
wait_timeout 28800

begemot · 2 февраля, 2008

PHPBB - действительно отстойный движок. И крупные трекеры рунета (torrents.ru, tfile.ru и др.), работающие на нём, точно так же лежат в DoS'e в вечернее время (только по московскому времени).

Однако, если железо сервера хватает и канал достаточно широк, то оптимизировать, безусловно, нужно конфиг PHP в его .ini-файле, но и здесь вряд ли кроектся истинная проблема ulanovka.ru.

По статистике в bottom'e страниц явно видно, что основная причина в MySQL! Следовательно, именно SQL-сервер и нцжно настраивать в первую очередь.

Здесь у phpbb появляется яркое преимущество - он поддерживает PostgreSQL. Это промышленная РСУБД, рядом с которой MySQL и рядом не стояла. Однако, необходима поддержка провайдера, предоставляющего хостинг-площадку, и перевод имеющейся базы из MySQL в Postgres, что является очень нетривиальной задачей.

Хотя, если не переходить на PostgreSQL, а продолжать "колдовать" над MySQL, то это будет не менее сложно! (:

дело в том, что MySQL показывает лучшие результаты в производительности (по сравнению с postgres) на определённых конфигурациях оборудования и (что очень важно!) при отностительно небольшом количестве запросов в секунду!

А при серьёзных нагрузках MySQL "падает", в то время как Postgres и "глазом не моргнёт"! (:

С такой проблемой MySQL сталкивается, например, всем известный ЖЖ (livejournal.com), который уже что только не придумывал для повышения устойчивости MySQL.

Самым эффективным улучшением является модуль mem_cache, однако, его можно использовать только если сервер- dedicated, то есть, если кроме ulanovka.ru ничего больше на сервере не хостится.

Добавлено:

Если идея о переходе на РСУБД PostgreSQL будет рассмотрена, то можно поискать автоматизированные способы перевода базы из MySQL.

например, здесь: http://www.lowlevel.cz/log/pivot/entry.php?id=101

MustDie · 2 февраля, 2008

Уже не первый раз сталкиваюсь вот с такой вот ошибкой


phpBB : Critical Error

Error creating new session

DEBUG MODE

SQL Error : 1114 The table 'phpbb_sessions' is full

INSERT INTO phpbb_sessions (session_id, session_user_id, session_start, session_time, session_ip, session_page, session_logged_in, session_admin) VALUES ('2cfe8b9ac0d1ca8a5adc028d713bc1b7', -1, 1201780999, 1201780999, '5abc2f2b', 0, 0, 0)

Line : 208
File : sessions.php

Из чего следует что это ошибка движка.

Что делаем:

1. Очистить табличку 'phpbb_sessions' в mySQL.

2. Увеличить максимально возможное кол-во одновременных сессий.

Если это не помогло то как все это автоматизировать можно почитать на бескрайних просторах инета.

С такой проблемой MySQL сталкивается, например, всем известный ЖЖ (livejournal.com)

Нагрузка livejournal.com не сравнима с нагрузкой ulanovka.ru так что думаю не стоит тут все валить на MySQL. 3000 с лишним юзеров думаю для MySQL посилам. Да и отказывать от apache я бы тоже не советовал, если хорошее железо то проблема не в этом.

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

Mac · 2 февраля, 2008

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

Да, нашел один очень страшный запрос в базу на главной странице. Убрал - существенно полегчало.

1. Очистить табличку 'phpbb_sessions' в mySQL.
2. Увеличить максимально возможное кол-во одновременных сессий.

с сессиями стоит мод для их ограничения и автоочистки. Видимо, не успевает просто очистить при большом количестве подключений.

Одновременных сессий стоит 160. На один ip - 2 сессии. Можно попробовать повысить первый показатель, но, боюсь, нагрузка возрастет.

mikhan · 10 февраля, 2008

на torrents.ru решили вопрос так

21. Почему мне всё время пишет "Извините, сервер перегружен"?!
Объяснения от глав. админа, зачем нужна эта табличка:
Те вычислительные мощности которые есть у нас просто не позволяют серверам обслужить всех желающих.
Именно поэтому мы вынуждены ограничить доступ к форуму.
Чтобы получить свободный доступ на форум нужно выполнить одно из следующих условий:
1) Стать активным участником любой зарегистрированной группы на форуме. Список групп здесь.
2) Иметь ратио >1 и UP >100ГБ
3) Иметь собственную раздачу, которую скачали 10 пользователей.

p.s. у них больше 7 тысяч человек одновременно, зарегистрированных более миллиона

Po$amax@ · 12 февраля, 2008

Следовало бы облегчить форум от ненужных ДБ MySQL и ненужных модов, например БашОрг квотера, замедляющего загрузку, просто поместить его в отдельный модуль, как SMS Sender, погоду Яндекса, т.к. я заметил, что после ее появления все стало грузиться намного тяжелее

Добавлено спустя 1 минуту 15 секунд:

Отключить GZIP сжатие SQL запросов, точнее данных СКуЛ

Mac · 12 февраля, 2008

ненужных модов, например БашОрг квотера, замедляющего загрузку, просто поместить его в отдельный модуль

башорг загружает 20 цитат с внешки раз в сутки. Все остальное время он берет их через php из тектовых файлов - это грузить не может.

погоду Яндекса, т.к. я заметил, что после ее появления все стало грузиться намного тяжелее

погода действует по тому же принципу - раз в час.

Отключить GZIP сжатие SQL запросов, точнее данных СКуЛ

включал/отключал - эффект одинаковый. Сейчас выключил.

Думаем насчет коллокэйшена. Подскажите минимальную конфигурацию железа для таких целей

Merlin · 12 февраля, 2008

для таких целей - это для каких конкретно?

сколько человек одновременно должен держать сервак?

1000? 2000? 3000?

...

10000?

думаю, вряд ли у нас в регионе есть сайты с такой посещаемостью..

так что, ориентироваться следует на советы западных коллег...

Po$amax@ · 12 февраля, 2008

убить репу - 2 запроса к SQL;

убить флаги - облегчение запроса к phpbb_users

убрать бота - может поможет

и еще + заметил, что на стбуровском форуме двига более тежелая и увесистая, но грузится быстрее. Гипотеза: может приоритет понизили на Улановку.ру ???

Mac · 12 февраля, 2008

для таких целей - это для каких конкретно?

известно, для каких. Для трекера.

сколько человек одновременно должен держать сервак?
1000? 2000? 3000?

Судя по стате трекера http://ulanovka.ru/forum/tracker-stat.php до 2000 пиров (лишь один GET-запрос в несколько минут, грузить сильно не должно) + до 150 юзеров онлайн на форуме.

убить репу - 2 запроса к SQL;

убирал запросы в топиках - не помогает. Хотя попробую анинсталлить.

убить флаги - облегчение запроса к phpbb_users

думаю, это очень несущественно.

убрать бота - может поможет

не, бот - эт как юзер.

Sk8erBoi · 18 февраля, 2008

phpinfo() перезалей

Mac · 18 февраля, 2008

phpinfo() перезалей

седня перезалью, как дома буду.

З.Ы. Мое расследование пришло к выводу, что беда в базе или ее структуре. Копаю дальше.

Bear · 18 февраля, 2008

mysql всетаки клиент-сервер, есть ли возможность завести на соседнем компе?

Mac · 20 февраля, 2008

phpinfo() перезалей

http://ulanovka.ru/phpinfo.php

mysql всетаки клиент-сервер, есть ли возможность завести на соседнем компе?

это вряд ли.

Sk8erBoi · 20 февраля, 2008

mysql всетаки клиент-сервер, есть ли возможность завести на соседнем компе?

Да, вот это было бы неплохо... поставить базу на отдельный копм, и помониторить нагрузку... может кто нить предоставить платформу для тестов?

p.s.: Есть утилитка mytop, она должна уметь показывать, какие именно запросы так тормозят систему. попроси админов ст показать ее вывод в часы пиковой нагрузки

Войти

Тормоза на Улановке. Фряшники, сисадмины, программисты, нужна помощь специалистов!

Рекомендуемые сообщения

Ссылка на комментарий

Гость bot

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Пожалуйста, войдите, чтобы комментировать

Последние посетители 0 пользователей онлайн