Оптимальная настройка mysql

MySQL OPTIMIZE TABLE

Before you do optimization, first confirm whether your MySQL database is suffering from fragmentation or not. To know it, run the below command.

Check Tables for Optimization

You need to analyze which table is consuming more space in your database. Hence, connect to the MySQL DB instance, and run the below query.

It should fetch the tables which are accounting for the unused space.

-- List all tables causing unused space
SELECT TABLE_NAME,
       ROUND(DATA_LENGTH/1024/1024) AS USED_SPACE_MB, 
       ROUND(DATA_FREE/1024/1024) AS UNUSED_SPACE_MB 
FROM INFORMATION_SCHEMA.TABLES 
WHERE ROUND(DATA_FREE/1024/1024) > 1000 
ORDER BY UNUSED_SPACE_MB;

After running the above SQL query, you shall see this type of result:

+------------+---------------+-----------------+
| TABLE_NAME | USED_SPACE_MB | UNUSED_SPACE_MB |
+------------+---------------+-----------------+
| EMPLOYEES  | 6917          | 5284            |
| SALESINFO  | 21473         | 11097           |
| FINANCES   | 11825         | 21286           |
+------------+---------------+-----------------+

We can interpret the following facts from the output:

• First, the SELECT command is listing all tables that are causing more than 1000 MB of free space.
• The columns USED_SPACE_MB and UNUSED_SPACE_MB are showing data in MB.
• The results indicate that all three tables are a candidate for optimization as they are causing high fragmentation.

MySQL OPTIMIZE TABLE Command

This command uses the following syntax:

mysql> OPTIMIZE TABLE table1  ...

We can use the above in one of the following ways:

First, we optimize one table using this MySQL statement.

mysql> OPTIMIZE TABLE EMPLOYEES;

Secondly, we can optimize multiple tables together, as shown below:

mysql> OPTIMIZE TABLE EMPLOYEES, SALESINFO, FINANCES;

While running optimization on a table, MySQL does the following tasks:

• Creates a temp table,
• Deletes the original one after optimizing it, and
• Rename the temp table to the original name in the end.

Post-MySQL Optimization

After finishing up with optimization, you can issue the below command. It will fetch the size of the total as well as the unused-space the three tables are claiming.

-- Query tables we'd optimized
SELECT TABLE_NAME,
       ROUND(DATA_LENGTH/1024/1024) AS USED_SPACE_MB, 
       ROUND(DATA_FREE/1024/1024) AS UNUSED_SPACE_MB 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_NAME in  
('EMPLOYEES', 'SALESINFO', 'FINANCES');

After running the above SQL query, you shall see this type of result:

+------------+---------------+-----------------+
| TABLE_NAME | USED_SPACE_MB | UNUSED_SPACE_MB |
+------------+---------------+-----------------+
| EMPLOYEES  | 3791          | 0               |
| SALESINFO  | 10012         | 0               |
| FINANCES   | 11005         | 0               |
+------------+---------------+-----------------+

You can easily deduce from the outcome that MySQL OPTIMIZE TABLE command has significantly reduced the size. And, unused space is no more.

Also, the table sizes have come down too. And it helped us fix a lot of fragmentation at the filesystem level.

Anyways, we hope that after wrapping up this tutorial, you should feel comfortable in optimizing the tables. However, you may practice more with examples to gain confidence.

Also, to learn SQL from scratch to depth, do read our step by step MySQL tutorial.

Оптимизация MySQL

Конфигурация MySQL достаточно сложная, но, к счастью, вам не нужно в нее сильно углубляться. Есть специальный скрипт под названием MySQLTunner, который анализирует работу MySQL и дает советы какие параметры нужно изменить и какие значения для них установить. Скрипт поддерживает большинство версий MariaDB, MySQL и Percona XtraDB. Нам понадобится загрузить три файла с помощью wget:

Первый из них — это сам скрипт, написанный на Perl, второй и третий — база данных простых паролей и уязвимостей. Они позволяют обнаружить проблемы с безопасностью. Дальше можно переходить к тестированию. Я использую сервер с настройками mysql по умолчанию, установленными панелью управления VestaCP.

Буквально за несколько минут скрипт выдаст полную статистику по работе MySQL. Количеству запросов, занимаемому объему памяти и эффективности работы буферов. Вы можете ознакомиться со всем этим, чтобы лучше понять в чем причина проблем. Проблемные места обозначены красными восклицательными знаками. Например, здесь мы видим, что размер буфера движка таблиц InnoDB (InnoDB buffer pool) намного меньше, чем должен быть для оптимальной работы:

Кроме того, в самом конце вывода утилита предоставит список рекомендаций как исправить ситуацию. Мы рассмотрим все сообщения утилиты из этого примера и почему нужно использовать именно их, а не другие.

Все параметры нужно добавлять в /etc/my.cnf. Еще раз замечу, что вы не копируете статью, а смотрите что вам выдала утилита. Начнем с query-cache.

Скрипт рекомендует отключить кэш запросов. Query Cache — это кэш вызовов SELECT. Когда базе данных отправляется запрос, она выполняет его и сохраняет сам запрос и результат в этом кэше. И все бы ничего, но при использовании его вместе с InnoDB при любом изменении совпадающих данных кэш будет перестраиваться, что влечет за собой потерю производительности. И чем больше объем кэша, тем больше потери. Кроме того при обновлении кэша могут возникать блокировки запросов. Таким образом, если данные часто пишутся в базу данных — его надежнее отключить.

Оба параметра устанавливают размер памяти, которая используется для внутренних временных таблиц MySQL. Утилита рекомендует использовать объем больше 16 мегабайт, просто установите это ваше значение для обоих переменных, если у вас достаточно памяти, то можно выделить 32 или даже 64

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

Этот параметр отвечает за количество потоков, которые будут закэшированны. После того, как работа с подключением будет завершена, база данных не разорвет его, а закэширует, если количество кэшированных потоков не превышает ограничение. Утилита рекомендует больше четырех, например, 16.

Указывает, что не нужно пытаться определить доменное имя для подключений извне. Ускоряет работу, так как не тратится время на DNS запросы.

Этот параметр определяет размер буфера InnoDB в оперативной памяти, от этого размера очень сильно зависит скорость выполнения запросов. Значение зависит от размера ваших таблиц и количества данных в них. Если памяти недостаточно, запросы будут обрабатываться дольше. У меня используется стандартный объем 128, а нужно больше 652.

Размер файла лога innodb должен составлять 25% от размера буфера. В случае 800 мегабайт это будет 200М. Но тут есть одна проблема. Чтобы изменить размер лога нужно выполнить несколько действий. Поскольку мы изменили все нужные параметры перейдем к перезагрузке сервера. Для нашего лога нужно остановить сервис:

Затем переместите файлы лога в /tmp:

И запустите сервис:

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

Отключение sync_binlog

Параметр sync_binlog определяет логику синхронизации данных из бинлога с диском. Если значение равно 1, запись на диск будет происходить после каждой транзакции. Это делает хранилище очень надежным, но крайне сильно нагружает дисковую подсистему на мастере.

Значение отключит синхронизацию из Mysql, и база данных будет полагаться на ОС в вопросе записи лога на диск. Такое значение может увеличить производительность мастера в несколько раз.

Проверить текущее значение можно так:

mysql -e "show variables like 'sync_binlog'"

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 1     |
+---------------+-------+

Отключить синхронизацию можно без перезагрузки сервера, для этого достаточно выполнить:

Однако не забудьте исправить этот параметр и в my.cnf, чтобы он сохранился после перезагрузки:

В .io мы всегда отключаем синхронизацию бинлога. Это увеличило пропускную способность наших Mysql узлов в 2…3 раза, разгрузив дисковые подсистемы мастеров.

Скорость работы MySQL

Оптимизация без аналитики бессмысленна. Перед тем как переходить к оптимизации давайте посмотрим как работает база данных сейчас, есть ли запросы, которые выполняются очень медленно. Все настройки вашего сервиса mysql находятся в файле /etc/my.cnf. Чтобы включить отображение медленных запросов добавьте такие строки в my.cnf, в секцию :

Здесь первая строка включает запись лога медленных запросов, вторая указывает, что минимальное время запроса для внесения его в этот лог — две секунды. Еще можно включить в лог запросы, которые не используют индексы:

Но это уже необязательно для проверки скорости и используется больше для отладки кода и правильности создания таблиц. Дальше перезапустите сервер баз данных и посмотрите лог:

Мы можем видеть, что есть запросы, которые выполняются больше, чем 10 секунд. Это, например, запрос

Можно его выполнить отдельно, в консоли mysql:

Здесь тоже измеряется время, и мы видим результат — три секунды. Это очень много. И еще ничего, если такие запросы приходят редко, если ваш сайт постоянно под нагрузкой, то тремя секундами вы не отделаетесь, количество необработанных запросов будет расти, а скорость ответа увеличиваться до нескольких минут. Можно пойти двумя путями — оптимизировать код, убрать сложные запросы, или же нужна оптимизация mysql на сервере.

Сжатие и оптимизация БД с типом таблиц InnoDB

Файлы ibdata1 и ib_log

На многих проектах с таблицами InnoDB встречается проблема с огромными размерами файлов ibdata1 и ib_log. Причина в большинвсте случае связан с неправильными настройками сервера MySQL/MariaDB или архитектурой БД. Вся информация из таблиц InnoDB хранится в файле ibdata1, пространство которого не высвобождается само по себе. Я предпочитаю хранить данные таблиц в отдельных файлах ibd*. Для этого нужно в конфигурационном файле my.cnf добавить строку:

innodb_file_per_table

или

innodb_file_per_table=1

Если же ваш сервер уже настроен и у вас есть несколько рабочих БД с таблицами InnoDB, нужно выполнить следующее:

1. Сделайте бэкап всех БД на своем сервере (кроме mysql и performance_schema). Дамп баз можно снять следующей командой:
2. После создания резервной копии БД остановите сервер mysql/mariadb;
3. Измените настройки в файле my.cfg;
4. Удалите файлы ibdata1 и ib_log файлы;
5. Запустите сервер mysql/mariadb;
6. Восстановите из бэкапа все БД:

После выполнения этой процедуры, все таблицы InnoDB будут хранится в отдельных файлах и файл ibdata1 не будет расти в геометрической прогрессии.

Сжатие таблиц InnoDB

Вы можете сжимать таблицы с данными типа text/BLOB. Если у вас есть подобные таблицы, вы можете сэкономить довольном много дискового пространства.

У меня имеется БД innodb_test с таблицами, которые потенциально можно сжать и высвободить дисковое пространство. Перед всеми работами я настоятельно рекомендую выполнить резервное копирование всех ваших БД. Подключаемся к серверу mysql:

В консоли mysql авторизуемся в нужной БД:

Чтобы вывести список таблиц и их размер, используйте запрос:

Где innodb_test — это имя вашей БД.

Есть вероятность, что некоторые таблицы можно сжать. Возьмём для примера таблицу b_crm_event_relations. Выполните запрос:

Query OK, 0 rows affected (3.27 sec)
Records: 0 Duplicates: 0 Warnings: 0

После выполнения, можно увидеть что за счет сжатия размер таблицы уменьшился с 26 до 11 Мб.

Благодаря сжатию таблиц вы можете сэкономить много дискового пространства на сервере. Но при работе со сжатыми таблицами вырастет нагрузка на процессор. Сжатие в таблицах нужно использовать, если у вас нет проблем с процессорными ресурсами, но есть проблема с местом на диске.

Tools That Can Help Optimize MySQL

In order to determine if your MySQL database needs to be reconfigured, it is best to look at how your resources are performing now. This can be done with the top command or with the Linode Longview service. At the very least, you should familiarize yourself with the RAM and CPU usage of your server, which can be discovered with these commands:

MySQLTuner

The MySQLTuner script assesses your MySQL installation, and then outputs suggestions for increasing your server’s performance and stability.

1. Download the MySQLTuner script:

2. Change the scripts permissions to be executable:

3. Run the script. You will be prompted to enter in your MySQL administrative login and password:

4. The script will return results similar to the output below:

   MySQLTuner offers suggestions regarding how to better the database’s performance. If you are wary about updating your database on your own, following MySQLTuner’s suggestions is one of the safer ways to improve your database performance.

Prepared Statements

Есть множество преимуществ в использовании prepared statements, как для безопасности, так и для улучшения производительности. Prepared statements фильтруют значения данных, добавляемых в запрос, что защищает запросы от SQL инъекций. Конечно, вы можете фильтровать переменные вручную, но тут может сказаться человеческая забывчивость и невнимательность

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

Вы можете использовать для prepared statement разные значения, но MySQL будет разбирать запрос только один раз.Кроме того, последние версии MySQL компилируют prepared statements в бинарную форму, что позволяет повысить эффективность.Раньше многие программисты избегали prepared statements по одной единственной причине — они не кэшировались MySQL, но с версии 5.1 это не так.Посмотрите mysqli extension для использования prepared statements или воспользуйтесь абстракцией базы данных, например, PDO.

1. // создаем a prepared statement
2. if ($stmt = $mysqli->prepare(«SELECT username FROM user WHERE state=?»)) {
3. // привязываем значения
4. $stmt->bind_param(«s», $state);
5. // выполняем
6. $stmt->execute();
7. // привязываем результат
8. $stmt->bind_result($username);
9. // получаем данные
10. $stmt->fetch();
11. printf(«%s is from %s\n», $username, $state);
12. $stmt->close();
13. }

Оптимизация настроек MySQL-сервера

Нас будет интересовать файл my.cnf. В Debian его можно найти в /etc/mysql/. Далее можно пойти разными путями. Первый — покурить форум VestaCP на тему готовых конфигов для похожей конфигурации сервера и попробовать их. Второй — углубиться в суть дела, использовать специальные утилиты для тестирования MySQL-сервера и запилить оптимальную конфигурацию для себя.

Курить форум — дело нехитрое, поэтому приведу лишь ссылку https://forum.vestacp.com. Для совсем ленивых приведу свою конфигурацию my.cnf, которая меня пока устраивает и позволила добиться адекватных показателей:

Конечно, всё это не претендует на идеальность и использовать эту конфигурацию можете только на свой страх и риск. Но для меня она работает хорошо.

Второй вариант — более сложный, но кому-то может быть интереснее, да и позволит более тонко настроить сервер. К тому же лишним опыт никогда не бывает. Я предлаю использовать две утилиты:

Индексируйте поля, по которым ищите

Индекс это не только основной или уникальный ключ. Это так же любые столбцы в таблице, которые вы используете для поиска и их можно проиндексировать.

Как вы можете заметить, это правило также применимо для части строк, например — «last_name LIKE ‘a%’». При поиске с начала строки, MySQL использует индекс этого столбца.Вы так же должны понимать, что это не сработает для регулярных выражений. Например, когда вы ищите слово (т.е. «WHERE post_content LIKE ‘%apple%’»), то от обычного индекса не будет никакого толку. Лучше будет использовать полнотекстовый поиск или создать вашу собственную систему индексации.

Настройка MySQL

При изменении конфигурации MySQL следует внимательно относиться к изменениям и их влиянию на базу данных. Даже при выполнении инструкций таких программ, как MySQLTuner, лучше иметь некоторое понимание процесса.

С порядком анализа можно ознакомиться .

Конфигурационный файл MySQL хранится в директории:

Для CentOS:

В этот файл могут быть внесены изменения, основанные на рекомендациях MySQLTuner в пункте Variables to adjust секции Recommendations. Если какого-либо параметра нет в файле my.cnf, допишите его.

После внесения изменений в my.cnf, перезагрузите MySQL-сервер:

• для Debian/Ubuntu и CentOS 6:

• для Centos 7:

Обратите внимание! Прежде чем проводить обновление конфигурации MySQL желательно создать бэкап. Для наиболее эффективного использования возможностей MySQLTuner желательно производить небольшие изменения за раз, а затем проводить повторный анализ

Таким итеративным способом можно будет добиться наилучших результатов при настройке MySQL

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

При этом, для того чтобы данные были корректны, необходимо, чтобы сервер MySQL проработал не менее 24 часов без перезагрузок и смены параметров конфигурации перед следующим анализом.

Tuning MySQL

When altering the MySQL configuration, be alert to the changes and how they affect your database. Even when following the instructions of programs such as , it is best to have some understanding of the process.

The MySQL configuration file stored in the following location: .

key_buffer

Changing the allocates more memory to MySQL, which can substantially speed up your databases, assuming you have the memory free. The size should generally take up no more than 25 percent of the system memory when using the MyISAM table engine, and up to 70 percent for InnoDB. If the value is set too high, resources are wasted.

According to MySQL’s documentation, for servers with 256MB (or more) of RAM with many tables, a setting of 64M is recommended. Servers with 128MB of RAM and fewer tables can be set to 16M, the default value. Websites with even fewer resources and tables can have this value set lower.

max_allowed_packet

This parameter lets you set the maximum size of a sendable packet. A packet is a single SQL state, a single row being sent to a client, or a log being sent from a master to a slave. If you know that your MySQL server is going to be processing large packets, it is best to increase this to the size of your largest packet. Should this value be set too small, you would receive an error in your error log.

thread_stack

This value contains the stack size for each thread. MySQL considers the default value of the variable sufficient for normal use; however, should an error relating to the be logged, this can be increased.

thread_cache_size

If is “turned off” (set to 0), then any new connection being made needs a new thread created for it. When the connections disengage the thread is destroyed. Otherwise, this value sets the number of unused threads to store in a cache until they need to be used for a connection. Generally this setting has little affect on performance, unless you are receiving hundreds of connections per minute, at which time this value should be increased so the majority of connections can be made on cached threads.

max_connections

This parameter sets the maximum amount of concurrent connections. It is best to consider the maximum amount of connections you have had in the past before setting this number, so you’ll have a buffer between that upper number and the value. Note, this does not indicate the maximum amount of users on your website at one time; rather it shows the maximum amount of users making requests concurrently.

Как ускорить запись

Увеличить производительность MySQL при большом объёме записи можно с помощью тонкой настройки параметров сервера.

По умолчанию InnoDB сбрасывает изменённые данные на диск с помощью системного вызова fsync(). При этом операционная система не гарантирует, что данные попадут в хранилища сию секунду, т.к. данные сперва проходят через буфер, поддерживаемый ядром. Буферизация необходима для ускорения ввода/вывода.

Однако если datadir MySQL расположен на аппаратном RAID-массиве, то есть возможность задействовать для такой буферизации NVRAM-кэш RAID-контроллера, что намного эффективнее. Следует только убедиться, что контроллер оснащён BBU (Battery Backup Unit) — отдельным источником питания для кэша. При внезапном отключении электропитания у контроллера должно быть время, чтобы сбросить содержимое кэша на диски, иначе данные в массиве останутся в неконсистентном состоянии.

При задействовании кэша RAID-контроллера повысить производительность операций записи в БД можно, отключив ненужную буферизацию на уровне операционной системы. Для этого требуется выставить переменную MySQL innodb_flush_method в значение O_DIRECT, после чего перезагрузить систему управления базы данных. Снизить нагрузку на диски также может изменение переменной innodb_flush_log_at_trx_commit. Для соответствия требованиям ACID движок InnoDB хранит логи транзакций, или redo-логи, в которые записываются все запросы на изменение данных. Эти логи используются в процессе восстановления после аварийного останова системы управления базами данных.

Значение по умолчанию (1) предполагает, что буфер redo-логов, расположенный в памяти InnoDB, записывается на диск после каждого коммита транзакции. Это наиболее безопасный режим работы, обеспечивающий сохранность каждой транзакции даже в случае “падения” сервера. Можно выставить innodb_flush_log_at_trx_commit в значение 2, тогда логи будут записываться также после каждого коммита, но fsync() — сброс данных на диск — будет выполняться лишь раз в секунду (начиная с версии MySQL 5.6.6 этот интервал определяется переменной innodb_flush_log_at_timeout). Аварийное завершение работы СУБД не приведёт к потере транзакций, однако отключение самого сервера может привести к потере последней секунды транзакций. Значение 0 подразумевает ещё более быстрый режим записи — данные и записываются, и синхронизируются раз в секунду, безотносительно коммитов транзакций. Однако innodb_flush_log_at_trx_commit=0 может привести к потере транзакций даже при падении процесса. Администратору базы данных нужно сделать выбор исходя из текущей нагрузки и бизнес-требований.

Оптимизировать дисковые операции записи помогает правильный выбор размера redo-логов. Для этого есть несложное правило. Достаточно замерить объём данных, который записан в лог за одну минуту. Эту операцию нужно выполнять в момент дневной пиковой нагрузки:

mysql> show global status like "Innodb_os_log_written"; select sleep(60); show global status like "Innodb_os_log_written";
+-----------------------+--------------+
| Variable_name         | Value        |
+-----------------------+--------------+
| Innodb_os_log_written | 337936892416 |
+-----------------------+--------------+
1 row in set (0.00 sec)
​
+-----------+
| sleep(60) |
+-----------+
|         0 |
+-----------+
1 row in set (1 min 0.01 sec)

+-----------------------+--------------+
| Variable_name         | Value        |
+-----------------------+--------------+
| Innodb_os_log_written | 337939448320 |
+-----------------------+--------------+
1 row in set (0.00 sec)

mysql> select (337939448320 - 337936892416) / 1024 / 1024 as innodb_log_written_per_min;
+----------------------------+
| innodb_log_written_per_min |
+----------------------------+
|                 2.43750000 |
+----------------------------+
1 row in set (0.00 sec)

mysql>

Из примера видно, что за минуту в лог InnoDB записывается 2,44 Мб данных. Объём лога следует подбирать таким образом, чтобы в него умещался объём данных за час. В таком случае у InnoDB будет достаточно времени, чтобы изменить порядок запросов на ввод/вывод для достижения последовательной записи. В нашем примере за один час через redo-логи проходит 150 Мб данных, поэтому переменную innodb_log_file_size следует выставить в значение не менее 75M. Если объём лога выбрать слишком большим, то увеличится время InnoDB Crash Recovery, что увеличит даунтайм при аварийном перезапуске (стоит отметить, что в MySQL 5.5 время Crash Recovery зависит от размера InnoDB-лога в меньшей степени).

Использование профиля для оптимизации

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

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

Существует еще одна возможность. Предположим, вы анализируете журнал мед­ленных запросов и находите простой запрос, на несколько запусков которого за­трачено неоправданно много времени, хотя он быстро запускался в тысячах других случаев. Вы снова запускаете запрос, и он выполняется молниеносно, как и должно быть. Применяете и обнаруживаете, что он правильно использует индекс. Вы пытаетесь использовать похожие запросы с разными значениями в разделе , чтобы убедиться, что запрос не обращается к кэшу, и они тоже выполняются быстро. Кажется, что с этим запросом все нормально. Что дальше?

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

Вас заинтересует / Intresting for you:

Модель развития базы данных My… 527 просмотров Ирина Светлова Thu, 10 Jan 2019, 12:29:03

Транзакции в базе данных MySQL 4511 просмотров Ирина Светлова Mon, 07 Jan 2019, 05:18:23

Выбор оптимальных типов данных… 1695 просмотров Валерий Павлюков Sun, 27 Oct 2019, 15:24:19

Обзор версий MySQL — какой рел… 2468 просмотров Ирина Светлова Thu, 10 Jan 2019, 08:02:16

Author: Aida

Другие статьи автора:

Отключаем (удаляем) ClamAV и SpamAssassin

Не думаю, что большинству рядовых пользователей нужны эти сервисы на их «домашних» VDS. А если ещё и ресурсы сервера сильно ограничены, то тем более. ClamAV весьма прожорлив и если у вас 1 Гб памяти (а меньше тем более), то он вам противопоказан. Отключить данные сервисы можно из самой панели в разделе Server, нажав Stop. В этом случае они будут остановлены, но при перезапуске сервера запустятся снова. Можно убрать из автозапуска, это делается по-разному в зависимости от дистрибутива. Инструкций масса, поэтому прошу воспользоваться поиском. Я же подошёл кардинально — удалил их. Вряд ли они когда-то пригодятся на сервере со столь малыми ресурсами. Тем более поставить обратно особых трудностей не составляет. Для удаления:

Теперь можно посмотреть на состояние памяти вышеназванными утилитами. Вероятно, что даже этого будет достаточно и проблема дефицита ОЗУ отпадёт. Но всё может оказаться не так просто и вы будете продолжать наблюдать нездоровый аппетит самого MySQL-сервера, а это значит, что нужно копать дальше в сторону его конфигурации, которую в варианте по умолчанию, сложно назвать оптимальной.