MySQL: оптимизация сервера с помощью скрипта mysqltuner. Mysql скрипт оптимизации
Скрипт для оптимизации Mysql — Linux портал
Скрипт, который может в выявлении проблемных мест конфигурации сервера mysql, и даст полезные советы по оптимизации. Скрипт написанный на языке perl и не просит установки. Его просто нужно скачать и запустить:$ cd /usr/local/bin$ wget http://mysqltuner.pl/mysqltuner.pl$ perl mysqltuner.pl
>> MySQLTuner 1.2.0 — Major Hayden
>> 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: rootPlease enter your MySQL administrative password:Скрипт попросит имя и пароль MySQL администратора, после чего выведет результаты своей работы.
«MySQL started within last 20 четыре hours — recommendations may be inaccurate»
оф. сайт MySQLTuner
Читаем еще:
- Оптимизация производительности Apache
- FTP сервер на базе vsftpd и MySQL в Debian (Ubuntu)
- Часто используемые команды для MySQL.
- Проверка Linux сервер на предмет взлома
- AWStats анализатор логов для статистики
Похожие статьи
-
Рекомендую
Оптимизация производительности Apache
Apache — популярный веб-сервер в интернет, он обслуживает неограниченное количество серверов и сайтов. Часто возникает необходимость прирастить производительность веб-сервера. Наверня...
-
SSH для обыденных смертных (авторизация по ключу)
SSH авторизация по ключуПредставим себе что у нас имеются 10-ки (о, ужас сотки машин) и к каждой необходимо запоминать различные пароли, а ставить один и тот же пароль не рекомендуется исходя из убе...
-
Внедрение mod_macro для конфигурации виртуальных хостов Apache
Лёгкое добавление новых виртуальных хостов в apache, в чём нам поможет модуль mod_macro.Установка для debian ubuntu mod_macro и включения.$ sudo apt-get install libapache2-mod-macro$ sudo a2enmod...
-
SSH для обыденных смертных
В сети много документов по настройке удалённого управления в Линукс и БСД-системах, но часто в их умалчиваются простые (после прокуривания мануалов и гуглежа) вещи. Непосредственно о их я расскаж...
-
SSH для обыденных смертных (возможности SSH)
Дополнительные возможности SSHКопирование файловиз командной строки употребляется команда scp.$ scp [file1] [user@host:file2]некоторые функции:-l limit — Ограничивает пропускную способность заданную...
hpunix.org
MySQL: оптимизация сервера с помощью скрипта mysqltuner
mysqltunerВладельцам серверов баз данных на основе MySQL рекомендую скачать и периодически запускать скрит mysqltuner, анализирующий текущее состояние и логи этого сервера и выдающий некоторые рекомендации для оптимизации работы сервера.
Этот скрипт дает подсказки - какими настройками или действиями можно повысить производительность сервера MySQL и как оптимизировать конфигурационные файлы.
Скачать скрипт можно по ссылке: ссылка.
Или прямо внутрь операционной системы:
Linux (Debian/CentOS):
$ wget http://mysqltuner.com/mysqltuner.pl
FreeBSD:$ fetch http://mysqltuner.com/mysqltuner.pl
Запускаем. При этом нас спрашивают логин и пароль суперпользователя (по-умолчанию - пользователя root).
$ ./mysqltuner.pl>> MySQLTuner 1.2.0 - Major Hayden <[email protected]>>> Bug reports, feature requests, and downloads at http://mysqltuner.com/>> Run with '--help' for additional options and output filteringPlease enter your MySQL administrative login: reagentPlease enter your MySQL administrative password:
-------- General Statistics --------------------------------------------------[--] Skipped version check for MySQLTuner script[OK] Currently running supported MySQL version 5.1.58-1~dotdeb.1[OK] Operating on 32-bit architecture with less than 2GB RAM
-------- Storage Engine Statistics -------------------------------------------[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster[--] Data in MyISAM tables: 607K (Tables: 29)[!!] InnoDB is enabled but isn't being used[!!] Total fragmented tables: 6
-------- Security Recommendations -------------------------------------------[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------[--] Up for: 7d 3h 38m 26s (101K q [0.165 qps], 9K conn, TX: 57M, RX: 16M)[--] Reads / Writes: 75% / 25%[--] Total buffers: 58.0M global + 2.7M per thread (151 max threads)[!!] Maximum possible memory usage: 463.8M (183% of installed RAM)[OK] Slow queries: 0% (0/101K)[OK] Highest usage of available connections: 2% (4/151)[OK] Key buffer size / total MyISAM indexes: 16.0M/191.0K[OK] Key buffer hit rate: 100.0% (3M cached / 171 reads)[OK] Query cache efficiency: 65.1% (36K cached / 56K selects)[OK] Query cache prunes per day: 0[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 6K sorts)[OK] Temporary tables created on disk: 19% (68 on disk / 354 total)[OK] Thread cache hit rate: 99% (4 created / 9K connections)[!!] Table cache hit rate: 2% (64 open / 2K opened)[OK] Open file limit used: 8% (82/1K)[OK] Table locks acquired immediately: 100% (61K immediate / 61K locks)
-------- Recommendations -----------------------------------------------------General recommendations: Add skip-innodb to MySQL configuration to disable InnoDB Run OPTIMIZE TABLE to defragment tables for better performance Reduce your overall MySQL memory footprint for system stability Enable the slow query log to troubleshoot bad queries Increase table_cache gradually to avoid file descriptor limitsVariables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** table_cache (> 64)
Как видно - результат свой скрипт вывалил сразу с рекомендациями по оптимизации и повышению производительности нашего MySQL сервера.Оптимизация конфигурации Mysql | SqR`s Blog
Наша задача установить оптимальные параметры конфигурации базы данных, для улучшения общей производительности Mysql и сервера в целом.
Изначально я перерыл кучи мануалов и рекомендаций по оптимальной настройке конфиги Mysql, очень много гемора и тестов! Mysql в принципе работал нормально, но меня очень настораживало, что иногда скул сам рестартился.Как то раз руки все таки дошли до логов, оказалось, что скулу не хватало памяти и он вылетал, что приводило иногда к повреждениям таблиц 🙁 Почему скул не использовал свап для меня так и осталось загадкой.
После установки Munin я оптимизировал работу апача? что дало пару сотен свободного рама. Это сподвигло меня выделить их для Mysql, в итоге были найдены два скрипта для автоматической помощи настройки my.cnf
Это MySQLTuner и MySQL Performance Tuning Primer Script
И так начнем с первого MySQLTuner
:Сайт: blog.mysqltuner.comСам скрипт: blog.mysqltuner.com/download/
1. Качаем
2. Устанавливаем права:
1 | chmod u+x mysqltuner.pl |
chmod u+x mysqltuner.pl
3. Запускаем:
4. Вводим логин и пароль рута:
1 2 | Please enter your MySQL administrative login: Please enter your MySQL administrative password: |
Please enter your MySQL administrative login: Please enter your MySQL administrative password:
Получаем что-то такого вида:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | -------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [!!] Your MySQL version 4.1.21-log is EOL software! Upgrade soon! [OK] Operating on 32-bit architecture with less than 2GB RAM -------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 1G (Tables: 2268) [--] Data in InnoDB tables: 896K (Tables: 56) [--] Data in HEAP tables: 1M (Tables: 2) [!!] Total fragmented tables: 200 -------- Performance Metrics ------------------------------------------------- [--] Up for: 2d 16h 1m 16s (7M q [30.639 qps], 587K conn, TX: 2B, RX: 1B) [--] Reads / Writes: 66% / 34% [--] Total buffers: 458.0M global + 27.2M per thread (70 max threads) [!!] Allocating > 2GB RAM on 32-bit systems can cause system instability [!!] Maximum possible memory usage: 2.3G (115% of installed RAM) [OK] Slow queries: 0% (1K/7M) [!!] Highest connection usage: 100% (71/70) [OK] Key buffer size / total MyISAM indexes: 64.0M/360.6K [OK] Key buffer hit rate: 99.9% (155M cached / 165K reads) [OK] Query cache efficiency: 52.3% (1M cached / 3M selects) [!!] Query cache prunes per day: 37386 [OK] Sorts requiring temporary tables: 0% (24 temp sorts / 149K sorts) [!!] Joins performed without indexes: 59355 [!!] Temporary tables created on disk: 31% (8K on disk / 25K total) [OK] Thread cache hit rate: 98% (6K created / 587K connections) [OK] Table cache hit rate: 20% (2K open / 9K opened) [OK] Open file limit used: 34% (3K/11K) [OK] Table locks acquired immediately: 99% (2M immediate / 2M locks) [OK] InnoDB data size / buffer pool: 896.0K/8.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections (> 70) wait_timeout (< 28800) interactive_timeout (< 28800) query_cache_size (> 128M) join_buffer_size (> 1020.0K, or always use indexes with joins) tmp_table_size (> 256M) max_heap_table_size (> 255M) |
-------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [!!] Your MySQL version 4.1.21-log is EOL software! Upgrade soon! [OK] Operating on 32-bit architecture with less than 2GB RAM -------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 1G (Tables: 2268) [--] Data in InnoDB tables: 896K (Tables: 56) [--] Data in HEAP tables: 1M (Tables: 2) [!!] Total fragmented tables: 200 -------- Performance Metrics ------------------------------------------------- [--] Up for: 2d 16h 1m 16s (7M q [30.639 qps], 587K conn, TX: 2B, RX: 1B) [--] Reads / Writes: 66% / 34% [--] Total buffers: 458.0M global + 27.2M per thread (70 max threads) [!!] Allocating > 2GB RAM on 32-bit systems can cause system instability [!!] Maximum possible memory usage: 2.3G (115% of installed RAM) [OK] Slow queries: 0% (1K/7M) [!!] Highest connection usage: 100% (71/70) [OK] Key buffer size / total MyISAM indexes: 64.0M/360.6K [OK] Key buffer hit rate: 99.9% (155M cached / 165K reads) [OK] Query cache efficiency: 52.3% (1M cached / 3M selects) [!!] Query cache prunes per day: 37386 [OK] Sorts requiring temporary tables: 0% (24 temp sorts / 149K sorts) [!!] Joins performed without indexes: 59355 [!!] Temporary tables created on disk: 31% (8K on disk / 25K total) [OK] Thread cache hit rate: 98% (6K created / 587K connections) [OK] Table cache hit rate: 20% (2K open / 9K opened) [OK] Open file limit used: 34% (3K/11K) [OK] Table locks acquired immediately: 99% (2M immediate / 2M locks) [OK] InnoDB data size / buffer pool: 896.0K/8.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections (> 70) wait_timeout (< 28800) interactive_timeout (< 28800) query_cache_size (> 128M) join_buffer_size (> 1020.0K, or always use indexes with joins) tmp_table_size (> 256M) max_heap_table_size (> 255M)
В итоге самое важное читаем после Recommendations:Оптимизируйте таблицы, используйте индексы, увеличте темпы для таблиц, используйте поменьше запросов с Limit и далее рекомендации по установке параметров.Но я бы не рекомендовал так спешить устанавливать и завышать параметры, внимательно посмотрите в раздел Performance Metrics, что у вас там сказано про использование памяти:[!!] Maximum possible memory usage: 2.3G (115% of installed RAM)т.е. у меня скул может сожрать на 15% больше доступного рама… что не гуд! лучшее значение это 90%
Примерная формула по которой вычисляется максимум использования памяти:
1 | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections |
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
Так что не перетрудитесь 🙂
Второй скрипт MySQL Performance Tuning Primer Script
Сайт: day32.com/MySQL/Сам скрипт: day32.com/MySQL/tuning-primer.sh2. Качаем:
1 | wget http://www.day32.com/MySQL/tuning-primer.sh |
wget http://www.day32.com/MySQL/tuning-primer.sh
2. Даем права
1 | chmod u+x tuning-primer.sh |
chmod u+x tuning-primer.sh
3. Запускаем
4. Указываем соккет, Вводим логин, пароль, создаем файл с настройками
1 2 3 4 5 | Would you like to provide a different socket?: [y/N] y Do you have your login handy ? [y/N] : y User: Password: Would you like me to create a ~/.my.cnf file for you? [y/N] : y |
Would you like to provide a different socket?: [y/N] y Do you have your login handy ? [y/N] : y User: Password: Would you like me to create a ~/.my.cnf file for you? [y/N] : y
Пример вывода:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | -- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery - MySQL Version 4.1.21-log i386 Uptime = 2 days 16 hrs 42 min 46 sec Avg. qps = 30 Total Questions = 7156747 Threads Connected = 27 Server has been running for over 48hrs. It should be safe to follow these recommendations To find out more information on how each of these runtime variables effects performance visit: http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html for info about MySQL's Enterprise Monitoring and Advisory Service SLOW QUERIES The slow query log is enabled. Current long_query_time = 1 sec. You have 1410 out of 7156763 that take longer than 1 sec. to complete Your long_query_time seems to be fine ............................................. TABLE SCANS Current read_buffer_size = 1 M Current table scan ratio = 541 : 1 read_buffer_size seems to be fine TABLE LOCKING Current Lock Wait ratio = 1 : 612 You may benefit from selective use of InnoDB. If you have long running SELECT's against MyISAM tables and perform frequent updates consider setting 'low_priority_updates=1' |
-- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery - MySQL Version 4.1.21-log i386 Uptime = 2 days 16 hrs 42 min 46 sec Avg. qps = 30 Total Questions = 7156747 Threads Connected = 27 Server has been running for over 48hrs. It should be safe to follow these recommendations To find out more information on how each of these runtime variables effects performance visit: http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html for info about MySQL's Enterprise Monitoring and Advisory Service SLOW QUERIES The slow query log is enabled. Current long_query_time = 1 sec. You have 1410 out of 7156763 that take longer than 1 sec. to complete Your long_query_time seems to be fine ............................................. TABLE SCANS Current read_buffer_size = 1 M Current table scan ratio = 541 : 1 read_buffer_size seems to be fine TABLE LOCKING Current Lock Wait ratio = 1 : 612 You may benefit from selective use of InnoDB. If you have long running SELECT's against MyISAM tables and perform frequent updates consider setting 'low_priority_updates=1'
Читаем, анализируем. Обращаем внимание на то где написано красным!
Для внесения изменений делаем бекап my.cnf
1 | cp -a /etc/my.cnf /etc/my.cnf.bak |
cp -a /etc/my.cnf /etc/my.cnf.bak
ну или ручками анпример в MCДалее рестартим mysql чтобы внесённые изменения вступили в силу.Через панель или командную строку… например:
1 | /etc/rc.d/init.d/mysqld restart |
/etc/rc.d/init.d/mysqld restart
После ждем часов 8-12, в принципе уже будет видно, полегчало или нет…
На данный момент мой сервер обрабаытвает примерно 30 запросов в секунду..За 2 дня 16 часов 42 минуты было обработано 7 156 747 без каких либо напрягов и свапов.После доводки конфига кеш стал использовать примерно на 25% лучше, вот скрин работы:
sqrs.ru
MySQLTuner :: High-performance MySQL optimization script
Полезный скрипт для проверки производительности вашей СУБД MySql.Внимание, перед запуском скрипта убедитесь, что СУБД работает в непрерывном режиме не менее 24 часов.
Скачиваем, устанавливаем и запускаем:
# wget http://github.com/rackerhacker/MySQLTuner-perl/zipball/v1.1.1Также можно воспользоваться git, чтобы получить последнюю версию:
git clone git://github.com/rackerhacker/MySQLTuner-perl.git # unzip rackerhacker-MySQLTuner-perl-v1.1.1-0-gb2dfc87.zip Archive: rackerhacker-MySQLTuner-perl-v1.1.1-0-gb2dfc87.zip b2dfc8789a531bbf848237a36fb984e346974e58 creating: rackerhacker-MySQLTuner-perl-b2dfc87/ inflating: rackerhacker-MySQLTuner-perl-b2dfc87/LICENSE inflating: rackerhacker-MySQLTuner-perl-b2dfc87/README inflating: rackerhacker-MySQLTuner-perl-b2dfc87/mysqltuner.pl # cd rackerhacker-MySQLTuner-perl-b2dfc87/ # chmod u+x mysqltuner.pl # ./mysqltuner.pl >> MySQLTuner 1.1.1 - Major Hayden <[email protected]> >> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering -------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.50-log [!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM -------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 69M (Tables: 1080) [--] Data in InnoDB tables: 15M (Tables: 312) [--] Data in MEMORY tables: 0B (Tables: 2) [!!] Total fragmented tables: 349 -------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned -------- Performance Metrics ------------------------------------------------- [--] Up for: 12m 28s (7K q [9.762 qps], 322 conn, TX: 16M, RX: 878K) [--] Reads / Writes: 97% / 3% [--] Total buffers: 1.0G global + 4.5M per thread (750 max threads) [!!] Allocating > 2GB RAM on 32-bit systems can cause system instability [!!] Maximum possible memory usage: 4.3G (144% of installed RAM) [!!] Slow queries: 7% (584/7K) [OK] Highest usage of available connections: 0% (2/750) [!!] Key buffer size / total MyISAM indexes: 8.0M/20.3M [!!] Key buffer hit rate: 85.3% (8K cached / 1K reads) [!!] Query cache efficiency: 18.9% (370 cached / 1K selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 60 sorts) [!!] Joins performed without indexes: 192 [!!] Temporary tables created on disk: 28% (1K on disk / 3K total) [OK] Thread cache hit rate: 99% (2 created / 322 connections) [OK] Table cache hit rate: 39% (1K open / 4K opened) [OK] Open file limit used: 29% (2K/8K) [OK] Table locks acquired immediately: 100% (2K immediate / 2K locks) [OK] InnoDB data size / buffer pool: 15.5M/900.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** key_buffer_size (> 20.3M) query_cache_limit (> 1M, or use smaller result sets) join_buffer_size (> 2.0M, or always use indexes with joins) tmp_table_size (> 16M) max_heap_table_size (> 20M)Related posts:
- Включение query cache в MySQL – улучшаем производительность Если выхотите оптимизировать скорость ответа вашего MySQL сервера, тогда вам...
- Asterisk – храним CDR в БД MySQL. Asterisk. Настройка. Статья#1. Складываем CDR в MySQL. Должны быть установлены...
from your own site.
nagg.ru
Оптимизация конфигурации Mysql, через mysqltuner
Наша задача установить оптимальные параметры конфигурации базы данных, для улучшения общей производительности Mysql и сервера в целом.
Изначально я перерыл кучи мануалов и рекомендаций по оптимальной настройке конфиги Mysql, очень много гемора и тестов! Mysql в принципе работал нормально, но меня очень настораживало, что иногда скул сам рестартился.
Как то раз руки все таки дошли до логов, оказалось, что скулу не хватало памяти и он вылетал, что приводило иногда к повреждениям таблиц Почему скул не использовал свап для меня так и осталось загадкой.
После установки Munin я оптимизировал работу апача? что дало пару сотен свободного рама. Это сподвигло меня выделить их для Mysql, в итоге были найдены два скрипта для автоматической помощи настройки my.cnf
Это MySQLTuner и MySQL Performance Tuning Primer Script
И так начнем с первого MySQLTuner
:
Сайт: blog.mysqltuner.com
Сам скрипт: blog.mysqltuner.com/download/
1. Качаем
2. Устанавливаем права:
1 | chmod u+x mysqltuner.pl |
3. Запускаем:
4. Вводим логин и пароль рута:
1 2 | Please enter your MySQL administrative login: Please enter your MySQL administrative password: |
Получаем что-то такого вида:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | -------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [!!] Your MySQL version 4.1.21-log is EOL software! Upgrade soon! [OK] Operating on 32-bit architecture with less than 2GB RAM -------- Storage Engine Statistics ------------------------------------------- [--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 1G (Tables: 2268) [--] Data in InnoDB tables: 896K (Tables: 56) [--] Data in HEAP tables: 1M (Tables: 2) [!!] Total fragmented tables: 200 -------- Performance Metrics ------------------------------------------------- [--] Up for: 2d 16h 1m 16s (7M q [30.639 qps], 587K conn, TX: 2B, RX: 1B) [--] Reads / Writes: 66% / 34% [--] Total buffers: 458.0M global + 27.2M per thread (70 max threads) [!!] Allocating > 2GB RAM on 32-bit systems can cause system instability [!!] Maximum possible memory usage: 2.3G (115% of installed RAM) [OK] Slow queries: 0% (1K/7M) [!!] Highest connection usage: 100% (71/70) [OK] Key buffer size / total MyISAM indexes: 64.0M/360.6K [OK] Key buffer hit rate: 99.9% (155M cached / 165K reads) [OK] Query cache efficiency: 52.3% (1M cached / 3M selects) [!!] Query cache prunes per day: 37386 [OK] Sorts requiring temporary tables: 0% (24 temp sorts / 149K sorts) [!!] Joins performed without indexes: 59355 [!!] Temporary tables created on disk: 31% (8K on disk / 25K total) [OK] Thread cache hit rate: 98% (6K created / 587K connections) [OK] Table cache hit rate: 20% (2K open / 9K opened) [OK] Open file limit used: 34% (3K/11K) [OK] Table locks acquired immediately: 99% (2M immediate / 2M locks) [OK] InnoDB data size / buffer pool: 896.0K/8.0M -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Reduce or eliminate persistent connections to reduce connection usage Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** max_connections (> 70) wait_timeout (< 28800) interactive_timeout (< 28800) query_cache_size (> 128M) join_buffer_size (> 1020.0K, or always use indexes with joins) tmp_table_size (> 256M) max_heap_table_size (> 255M) |
В итоге самое важное читаем после Recommendations:
Оптимизируйте таблицы, используйте индексы, увеличте темпы для таблиц, используйте поменьше запросов с Limit и далее рекомендации по установке параметров.
Но я бы не рекомендовал так спешить устанавливать и завышать параметры, внимательно посмотрите в раздел Performance Metrics, что у вас там сказано про использование памяти:
[!!] Maximum possible memory usage: 2.3G (115% of installed RAM)
т.е. у меня скул может сожрать на 15% больше доступного рама… что не гуд! лучшее значение это 90%
Примерная формула по которой вычисляется максимум использования памяти:
1 | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections |
Так что не перетрудитесь
Второй скрипт MySQL Performance Tuning Primer Script
Сайт: day32.com/MySQL/
Сам скрипт: day32.com/MySQL/tuning-primer.sh
1. Качаем:
1 | wget http://www.day32.com/MySQL/tuning-primer.sh |
2. Даем права
1 | chmod u+x tuning-primer.sh |
3. Запускаем
4. Указываем соккет, Вводим логин, пароль, создаем файл с настройками
1 2 3 4 5 | Would you like to provide a different socket?: [y/N] y Do you have your login handy ? [y/N] : y User: Password: Would you like me to create a ~/.my.cnf file for you? [y/N] : y |
Пример вывода:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | -- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery - MySQL Version 4.1.21-log i386 Uptime = 2 days 16 hrs 42 min 46 sec Avg. qps = 30 Total Questions = 7156747 Threads Connected = 27 Server has been running for over 48hrs. It should be safe to follow these recommendations To find out more information on how each of these runtime variables effects performance visit: http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html for info about MySQL's Enterprise Monitoring and Advisory Service SLOW QUERIES The slow query log is enabled. Current long_query_time = 1 sec. You have 1410 out of 7156763 that take longer than 1 sec. to complete Your long_query_time seems to be fine ............................................. TABLE SCANS Current read_buffer_size = 1 M Current table scan ratio = 541 : 1 read_buffer_size seems to be fine TABLE LOCKING Current Lock Wait ratio = 1 : 612 You may benefit from selective use of InnoDB. If you have long running SELECT's against MyISAM tables and perform frequent updates consider setting 'low_priority_updates=1' |
Читаем, анализируем. Обращаем внимание на то где написано красным!
Для внесения изменений делаем бекап my.cnf
1 | cp -a /etc/my.cnf /etc/my.cnf.bak |
ну или ручками анпример в MC
Далее рестартим mysql чтобы внесённые изменения вступили в силу.
Через панель или командную строку… например:
1 | /etc/rc.d/init.d/mysqld restart |
После ждем часов 8-12, в принципе уже будет видно, полегчало или нет…
На данный момент мой сервер обрабаытвает примерно 30 запросов в секунду..
За 2 дня 16 часов 42 минуты было обработано 7 156 747 без каких либо напрягов и свапов.
После доводки конфига кеш стал использовать примерно на 25% лучше, вот скрин работы:
https://www.sqrs.ru/2009/10/22/82/
Просмотров: 1405
Похожие посты
proggear.ru
Использование mysqltuner для оптимизации работы MySQL
Системным администраторам часто приходится работать с техническими площадками для размещения веб-сайтов. Как правило, для большинства распространенных CMS в качестве БД используют MySQL. От стабильной и быстрой работы СУБД MySQL зависит и скорость работы самого сайта. Для анализа и устранения возможных проблем в работе БД системные администраторы часто используют утилиту mysqltuner.
Параметры работы MySQL можно посмотреть как с самой командной строки так и с помощью различных дополнительных инструментов (например, PhpMyAdmin). Преимущество mysqltuner в том, что он представляет информацию о MySQL и основных текущих параметрах работы в удобном и понятном виде. Кроме этого, в случае явных проблем, выдает рекомендации по изменению проблемных параметров.
Для анализа состояния MySQL достаточно скачать скрипт
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
Дать права на выполнение
chmod +x mysqltuner.pl
Выполнить запуск скрипта
./mysqltuner.pl
В Debian-подобных дистрибутивах анализ начнется сразу, поскольку для подключения к БД скрипт использует системные параметры доступа, которые указаны в /etc/mysql/debian.cnf. Для RedHat-подобных дистрибутивах пареметры подключения (логин/пароль) необходимо указывать отдельно.
Пример использования mysqltuner:
./mysqltuner.pl
[OK] Logged in using credentials from debian maintenance account.[OK] Currently running supported MySQL version 5.5.34-0ubuntu0.12.04.1[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics ---------------------------------[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM[--] Data in MyISAM tables: 123M (Tables: 12)[--] Data in InnoDB tables: 592M (Tables: 4)[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)[--] Data in MEMORY tables: 3M (Tables: 3)[--] Data in BLACKHOLE tables: 0B (Tables: 1)[!!] Total fragmented tables: 5
-------- Security Recommendations ---------------------------------[OK] All database users have passwords assigned
-------- Performance Metrics ---------------------------------------[--] Up for: 8d 13h 53m 41s (89M q [120.857 qps], 11K conn, TX: 537B, RX: 287B)[--] Reads / Writes: 29% / 71%[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)[OK] Maximum possible memory usage: 597.8M (3% of installed RAM)[OK] Slow queries: 0% (1/89M)[OK] Highest usage of available connections: 29% (45/151)[OK] Key buffer size / total MyISAM indexes: 16.0M/429.0K[OK] Key buffer hit rate: 100.0% (164M cached / 124 reads)[OK] Query cache efficiency: 36.8% (8M cached / 22M selects)[OK] Query cache prunes per day: 0[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 129 sorts)[OK] Temporary tables created on disk: 5% (366 on disk / 6K total)[OK] Thread cache hit rate: 98% (134 created / 11K connections)[OK] Table cache hit rate: 30% (100 open / 332 opened)[OK] Open file limit used: 0% (90/20K)[OK] Table locks acquired immediately: 99% (46M immediate / 46M locks)[!!] InnoDB buffer pool / data size: 128.0M/592.5M[OK] InnoDB log waits: 0-------- Recommendations -------------------------------------------General recommendations:Run OPTIMIZE TABLE to defragment tables for better performanceEnable the slow query log to troubleshoot bad queriesVariables to adjust:innodb_buffer_pool_size (>= 592M)
Полученные данные помогают понять что именно нужно изменить в конфигурации базы. Кроме этого получаем много полезной информации по работе БД. Например, размер данных в БД, время беспрерывной работы, количество и интенсивность запросов, и т.д.
Важное замечание по работе с mysqltuner. Анализ необходимо производить после некоторого беспрерывного периода работы БД. Например, 24 часа, а лучше несколько дней. В таком случае скрипт даст более точную и полезную информацию.
Не стоит забывать, что полученные в результате работы скрипта данные не всегда укажут на узкое место. Для общего анализа работы их может быть достаточно. Но для более тонкой настройки MySQL под определенные задачи может потребоваться более детальный анализ и тестирование.
rubuntu.com
Оптимизация скриптов командной строки php для обработки больших плоских файлов
Для фейри с нисходящим потоком. Я знаю, что php является неправильным языком для этого ... но я работаю под внешними ограничениями. Учитывая, что:
У меня есть большой плоский файл, который мне нужно обрабатывать в php. Я конвертирую плоский файл в нормализованную базу данных в mysql. В плоском файле имеется несколько миллионов строк.
Первоначально я пытался использовать систему ORM при импорте плоского файла. С этой конструкцией возникла серьезная проблема с утечкой памяти php даже при тщательном освобождении объектов. Даже если я гарантирую, что хватит памяти, сценарию потребуется около 25 дней для работы на моем рабочем столе.
Я удалил накладные расходы и переписал сценарий, чтобы напрямую строить команды mysql. Я удалил AUTO INCREMENT из моего дизайна, так как это потребовало от меня, как Mysql, что последний идентификатор был введен для установления отношений между точками данных. Я просто использую глобальный счетчик для идентификаторов базы данных, и я никогда не занимаюсь поиском, просто вставляет.
Я использую команду разделения unix для создания большого количества небольших файлов вместо одного большого, потому что есть лишние ресурсы памяти, связанные с использованием указателя файла снова и снова.
Использование этих оптимизаций (надеюсь, они помогут кому-то еще) Я получил скрипт импорта, который будет работать примерно через 6 часов.
Я арендовал виртуальный экземпляр с 5-кратной ОЗУ и примерно в 5 раз больше мощности процессора, чем мой рабочий стол, и заметил, что он прошел точно так же быстро. Сервер запускает процесс, но имеет запасные циклы процессора и оперативную память. Возможно, ограничивающим фактором является скорость диска. Но у меня много ОЗУ. Должен ли я как-то загружать файлы в память? Любые предложения по дальнейшей оптимизации скриптов командной строки php, обрабатывающих большие файлы, приветствуются!
stackoverrun.com