- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте у меня проблема с аномальной нагрузкой на mysql.
Собственно стоит задача игровой сервер в обычное время показатели в atop показывают:
DSK | sda | busy 31% | read 0 | write 397 | avio 7.66 ms |
DSK | sdb | busy 29% | read 0 | write 397 | avio 7.23 ms |
Но есть у наших проектов такое как автосейф игроков 1 раз в 15 минут. 2 игровых проекта.
Нагрузка возрастает до 90% в связи с чем начинаются те же лаги. Бывает и без сейвов нагрузка достигает 85% опять же начинаются лаги..
На повестке дня возник еще 1 проект игровой с большей уже базой. Но меньше игроков(значит отдача будет меньше)
Вопрос стоит в том, есть ли смысл покупать SSD диски на сервер? Сейчас имеется в распоряжении машина:
4 c/ 8 t
2.66 GHz+
32 GB
2 x 2 TB SATA
Что касается процессора и оперативки то процессор нагружен от силы 10-15% оперативка в среднем при аптайме от 3 дней работы серверов достигает 15 гигабайт. На борту Debian linux 7.5
Сам конфиг mysql:
Тюнер говорит вот что:
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.41-0+wheezy1-log
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1G (Tables: 714)
[--] Data in InnoDB tables: 4G (Tables: 266)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 119
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 29d 2h 32m 56s (591M q [235.131 qps], 11M conn, TX: 591B, RX: 87B)
[--] Reads / Writes: 30% / 70%
[--] Total buffers: 6.1G global + 35.4M per thread (3048 max threads)
[!!] Maximum possible memory usage: 111.6G (354% of installed RAM)
[OK] Slow queries: 0% (2K/591M)
[OK] Highest usage of available connections: 17% (532/3048)
[OK] Key buffer size / total MyISAM indexes: 200.0M/104.2M
[OK] Key buffer hit rate: 100.0% (754M cached / 33K reads)
[OK] Query cache efficiency: 90.1% (410M cached / 455M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (2K temp sorts / 7M sorts)
[OK] Temporary tables created on disk: 1% (69K on disk / 5M total)
[OK] Thread cache hit rate: 99% (21K created / 11M connections)
[!!] Table cache hit rate: 17% (2K open / 13K opened)
[OK] Open file limit used: 0% (2K/907K)
[OK] Table locks acquired immediately: 99% (149M immediate / 149M locks)
[!!] InnoDB data size / buffer pool: 4.8G/4.4G
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
table_cache (> 452152)
innodb_buffer_pool_size (>= 4G)
В конфиге много значений в основном это старый конфиг и составлять его помогала еще тех поддержка со временем я поднял некоторые значения.. Прочитав в интернете про почти все параметры, я так и не понял про параметр table_cache.
Ах.. Ну и memlock мы поставили уже сами без тех. поддержки вычитав это в интернете.
Дак вот.. Есть ли смысл покупать SSD диски? Или можно тут подрегулировать параметры некоторые. Спасибо за помощь!:)
Купите и не парьтесь. Главное бэкапы делайте и всё.
Купите и не парьтесь. Главное бэкапы делайте и всё.
Купить конечно не проблема, но всё же интересно насчёт парметров моих mysql скажем так у конкурентов по слухам нагрузка 10-15. Когда у меня она же составляет 25-30
innodb_buffer_pool_size увеличте до 5Гб
query_cache_size=1G - не многовато?
http://www.mysql.ru/docs/man/Table_cache.html тут читали ?
innodb_buffer_pool_size увеличте до 5Гб
query_cache_size=1G - не многовато?
http://www.mysql.ru/docs/man/Table_cache.html тут читали ?
Насчёт 1g это тех поддержка так поставила.
Насчёт тейбл кеша читали, но просто интересует это аномальное значение которое опять же тех поддержка поставила
table_cache = 452152
ну и еще напрягает тот момент
[!!] Maximum possible memory usage: 111.6G (354% of installed RAM)
:)
И в данном случае он еще требует увеличить это значение?
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
table_cache (> 452152)
хмм, можно попробвать убрать резолвинг адресов, тоетсь что бы все шло к примеру по ип адресу (127,0,0,1)
У меня сервер на интеловских ссд 3500 серии, ссд выносливые.
иннодб я оптимизирую так.
по умолчанию иннодб использует один инстант.
Общий объем каждого инстатнта.
четыре блока(инстанта) по одному гигу.
Чтение/запись диска, максимум 8 помоему.
Чтение/запись диска, максимум 8 помоему.
Использовать все 12ядер.
innodb_thread_concurrency = 12
skip-networking
skip-name-resolve
Подробнее можно прочитать тут.
http://habrahabr.ru/company/bitrix/blog/148874/
У вас реально так много таблиц в базе?
table_cache = 452152
хмм, можно попробвать убрать резолвинг адресов, тоетсь что бы все шло к примеру по ип адресу (127,0,0,1)
У меня сервер на интеловских ссд 3500 серии, ссд выносливые.
иннодб я оптимизирую так.
по умолчанию иннодб использует один инстант.
Общий объем каждого инстатнта.
четыре блока(инстанта) по одному гигу.
Чтение/запись диска, максимум 8 помоему.
Чтение/запись диска, максимум 8 помоему.
Использовать все 12ядер.
innodb_thread_concurrency = 12
skip-networking
skip-name-resolve
Подробнее можно прочитать тут.
http://habrahabr.ru/company/bitrix/blog/148874/
У вас реально так много таблиц в базе?
table_cache = 452152
Спасибо посмотрю ваши настройки обязательно! Ну у нас каждый проект кушает по 3 базы в каждой базе по 100-150 таблиц +apache-2 базы по 10-20 таблиц
У вас есть лог медленных запросов. Почему вы не начали с их анализа ?
Насчёт 1g это тех поддержка так поставила.
А вы все равно уменьшайте. 128M даже достаточно.
Сделайте еще innodb_flush_log_at_trx_commit=2
или 0. Да, это может быть опасно, но не в онлайн играх.
Битрикс, например, рекомендовал так делать. А битрикс - голова!
[!!] Maximum possible memory usage: 111.6G (354% of installed RAM)
И в данном случае он еще требует увеличить это значени
mysqltuner ничего не требует. Вы сами легко все испортите.
Если известно, что количество подключений ограничено другими факторами, например MaxClients в apache, то потребляемая память никогда этого значения не достигнет.
У вас есть лог медленных запросов. Почему вы не начали с их анализа ?
А вы все равно уменьшайте. 128M даже достаточно.
Сделайте еще innodb_flush_log_at_trx_commit=2
или 0. Да, это может быть опасно, но не в онлайн играх.
Битрикс, например, рекомендовал так делать. А битрикс - голова!
mysqltuner ничего не требует. Вы сами легко все испортите.
Если известно, что количество подключений ограничено другими факторами, например MaxClients в apache, то потребляемая память никогда этого значения не достигнет.
Спасибо!
Хорошо сделаю как вы посоветовали, но можно поподробнее насчёт innodb_flush_log_at_trx_commit = 2 пока что поставил 2 боюсь насчёт 0 :) В интернете пишут что потеря данных при аварийной остановке mysql значит ли это, что я потеряю всю базу? или что я потеряю если при 0 просто убью процесс через killall к примеру
denisakajacob, может потеряться новая информация за несколько последних секунд.
Можно решить проблему кардинально и заменить innodb на tokudb, который оптимизирован под подобные нагрузки, много пишущие в базу, во много раз больше вытянет:
http://www.tokutek.com/tokudb-for-mysql/