Новые изменения настройки my.cnf в 2021 году
Времена идут, знания становятся лучше, поэтому я уже практически во многом перенастроил свои файлы конфигов базы данных. Сразу скажу, что в основном этот конфиг рассчитан по моим базам данных, это порядка 14 гигабайт данных на серверах с 32 памяти оперативной, ssd дисками и собственно выкручено все на соотношение скорость работы + стабильность. Поэтому вот такой конфиг сейчас использую на Centos 8 с указанными параметрами серверов.
PHP
collation-server = utf8_general_ci
character-set-server = utf8
local-infile=0
innodb_file_per_table = 1
skip-log-bin = true
symbolic-links=0
skip-external-locking
skip-name-resolve
max-connect-errors = 1000
low-priority-updates=1
max_allowed_packet = 32M
open_files_limit = 165536
key_buffer_size = 512m
max_connections = 150
thread-cache-size = 150
wait_timeout = 90
interactive_timeout = 90
innodb_buffer_pool_instances = 16
innodb_buffer_pool_size = 16G
innodb_thread_concurrency = 32
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb-log-files-in-group = 2
innodb_log_file_size = 2g
innodb_log_buffer_size = 16M
|
1 |
collation-server=utf8_general_ci character-set-server=utf8 local-infile= innodb_file_per_table=1 skip-log-bin=true symbolic-links= skip-external-locking skip-name-resolve max-connect-errors=1000 low-priority-updates=1 max_allowed_packet=32M open_files_limit=165536 key_buffer_size=512m max_connections=150 thread-cache-size=150 wait_timeout=90 interactive_timeout=90 innodb_buffer_pool_instances=16 innodb_buffer_pool_size=16G innodb_thread_concurrency=32 innodb_flush_log_at_trx_commit= innodb_flush_method=O_DIRECT innodb-log-files-in-group=2 innodb_log_file_size=2g innodb_log_buffer_size=16M |
В принципе производительность и уровень работы меня устраивает. Если у вас есть вопросы или конфигурация сервера другая, желательно написать все таки вопрос, я помогу разобраться какие параметры следует учесть. Из основного: сделан упор на работу Innodb + конфиги учитывают максимально настройки устраняющие узкие места в работе базы данных.
Перенос временных файлов MySQL в память
Проверяем наличие /dev/shm:
df -h
| 1 | df-h |
Настройки размещаются в , рекомендуем указать размер, например, 1G:
none /dev/shm tmpfs defaults,size=1G 0 0
| 1 | nonedevshm tmpfs defaults,size=1G |
Если внесли изменения, то перемонтируем:
mount -o remount /dev/shm
| 1 | mount-oremountdevshm |
В конфигурационном файле указываем:
tmpdir = /dev/shm
| 1 | tmpdir=devshm |
В случае, если используется Apparmor, то внесите используемый путь (/dev/shm или /run/mysql) в конфигурационный файл /etc/apparmor.d/usr.sbin.mysqld, например:
/run/mysql/* rw,
| 1 | runmysql*rw, |
Затем перезапустите:
service apparmor restart
| 1 | service apparmor restart |
Параметры MySQL
key_buffer
Изменение выделяет больше памяти MySQL, что существенно ускоряет работу базы данных при условии наличия свободной памяти. Размер обычно должен занимать не более 25% системной памяти при использовании MyISAM и до 70% для InnoDB. Если значение установлено слишком высоко, ресурсы расходуются впустую.
Согласно документации MySQL, для серверов с 256MB (или более) ОЗУ с множеством таблиц рекомендуется настройка 64M. Серверы с 128MB ОЗУ и меньшим количеством таблиц могут быть настроены на 16M — это значение по умолчанию. Веб-сайты с еще меньшим числом ресурсов и таблиц могут быть ограничены даже меньшим объемом.
max_allowed_packet
Этот параметр позволяет задать максимальный размер отправляемого пакета. Если известно, что MySQL-сервер будет обрабатывать большие пакеты, лучше увеличить их до размера самого большого пакета. Если это значение будет слишком маленьким, в журнале ошибок появится ошибка.
thread_stack
Это значение содержит размер стека для каждого треда. MySQL считает значение переменной по умолчанию достаточным для нормального использования. Однако в случае регистрации ошибки, связанной с , оно может быть увеличено.
thread_cache_size
Этот параметр указывает количество тредов, которые уходят в кеш при отключении клиента. При новом подключении тред используется из кеша, что позволяет экономить ресурсы при значительных нагрузках.
max_connections
Этот параметр задает максимальное количество одновременных подключений. Прежде чем задавать это число, лучше всего учитывать максимальное количество подключений, которые были в прошлом, следовательно у вас будет буфер между верхним числом подключений и значением
Следует обратить внимание на то, что этот параметр не указывает максимальное количество пользователей на сайте. Вместо этого отображается максимальное количество пользователей, одновременно делающих запросы
table_cache
Это значение должно быть больше, чем значение . Для определения этого значения используйте:
С полным перечнем анализируемых параметров можно ознакомиться здесь.
Исходные данные для настройки
Итак рассматриваем систему с установленным ISP manager на котором стоит Centos и MariaDB. Задача, оптимизировать работу Mysql и ускорить тем самым обработку запросов на сайтах. Для начала я приведу, пример своего my.cnf который находится по адресу etc/my.cnf, если у вас стоит Debian то смотреть надо в папке другой. Итак вот так выглядит настроенный файл, но иногда я все таки еще изменяю некоторые настройки, о которых расскажу ниже.
PHP
#open_files_limit = 2000
local-infile=0
innodb_file_per_table = 1
pid-file = /var/run/mysqld/mysqld.pid
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
ignore-db-dir=lost+found
max_allowed_packet = 1024M
skip-external-locking
skip-name-resolve
key_buffer = 2G
key_cache_division_limit = 70
thread_stack = 192K
tmp_table_size = 2G
max_heap_table_size = 2G
key_buffer_size = 4G
sort_buffer_size = 1G
read_buffer_size = 1G
read_rnd_buffer_size = 2G
myisam-recover = BACKUP
max_connections = 500
table-cache = 120000
table-open-cache = 120000
thread-cache-size = 500
thread-cache-size = 500
interactive-timeout = 360
query_cache_limit = 12M
query_cache_size = 4G
join_buffer_size = 512M
#log_slow_queries = /var/log/mysql/mysql-slow.log
expire_logs_days = 10
max_binlog_size = 100M
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
symbolic-links=0
bind-address = 127.0.0.1
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d
|
1 |
mysqld #open_files_limit = 2000 local-infile= innodb_file_per_table=1 pid-file=varrunmysqldmysqld.pid datadir=varlibmysql socket=varlibmysqlmysql.sock ignore-db-dir=lost+found max_allowed_packet=1024M skip-external-locking skip-name-resolve key_buffer=2G key_cache_division_limit=70 thread_stack=192K tmp_table_size=2G max_heap_table_size=2G key_buffer_size=4G sort_buffer_size =1G read_buffer_size =1G read_rnd_buffer_size=2G myisam-recover=BACKUP max_connections=500 table-cache=120000 table-open-cache=120000 thread-cache-size=500 thread-cache-size=500 interactive-timeout=360 query_cache_limit=12M query_cache_size =4G join_buffer_size=512M expire_logs_days=10 max_binlog_size =100M innodb_buffer_pool_size=4G innodb_buffer_pool_instances=4 innodb_flush_log_at_trx_commit=2 innodb_flush_method=O_DIRECT symbolic-links= bind-address=127.0.0.1 mysqld_safe log-error=varlogmariadbmariadb.log pid-file=varrunmariadbmariadb.pid !includediretcmy.cnf.d |
Тюнинг базы данных Mysql варианты
Итак что я меняю и что вижу при этом. Для начала выведу основные параметры которые считаю спорными в настройке.
PHP
key_buffer = 2G
key_cache_division_limit = 70
thread_stack = 192K
tmp_table_size = 1G
max_heap_table_size = 1G
key_buffer_size = 4G
sort_buffer_size = 1G
read_buffer_size = 1G
read_rnd_buffer_size = 2G
myisam-recover = BACKUP
max_connections = 500
table-cache = 120000
table-open-cache = 120000
thread-cache-size = 500
interactive-timeout = 360
query_cache_limit = 12M
query_cache_size = 4G
join_buffer_size = 512M
|
1 |
key_buffer=2G key_cache_division_limit=70 thread_stack=192K tmp_table_size=1G max_heap_table_size=1G key_buffer_size=4G sort_buffer_size =1G read_buffer_size =1G read_rnd_buffer_size=2G myisam-recover =BACKUP max_connections =500 table-cache=120000 table-open-cache=120000 thread-cache-size=500 interactive-timeout=360 query_cache_limit=12M query_cache_size =4G join_buffer_size=512M |
Настройка 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 часов без перезагрузок и смены параметров конфигурации перед следующим анализом.
Установка
-
Скачайте MySQLTuner:
Для удобства можно воспользоваться штатными репозиториями и установить MySQLTuner.
Для Debian/Ubuntu:
Для CentOS:
-
Разрешите выполнение скрипта:
-
Запустите скрипт mysqltuner.pl. Вам будет предложено ввести имя пользователя и пароль администратора MySQL:
Если производилось скачивание скрипта:
Если производилась установка:
-
Если возникла ошибка:
Запустите с с ключом :
-
Скрипт вернет результаты анализа, аналогичные представленным ниже:
MySQLTuner предлагает способы повышения производительности базы данных. Если самостоятельно обновить конфигурацию базы данных затруднительно, то выполнение рекомендаций MySQLTuner является одним из безопасных способов повышения производительности.
4 ответа
Лучший ответ
Ubuntu перешла с Upstart на Systemd в версии 15.04 и больше не соблюдает ограничения в /etc/security/limits.conf для системных служб. Эти ограничения теперь применяются только к пользовательским сеансам.
Ограничения для службы MySQL определены в файле конфигурации Systemd, который вы должны скопировать из его расположения по умолчанию в / etc / systemd, а затем отредактировать копию.
Добавьте следующие строки в конец файла:
Вы также можете установить числовой предел, например .
Теперь перезагрузите конфигурацию Systemd с помощью:
Перезапустите MySQL, и теперь он должен подчиняться директиве max_connections.
У меня также были проблемы с чистой остановкой MySQL после обновления до 15.04. Если это повлияет на вас (вы будете знать, потому что время ожидания займет 300 секунд, когда вы сделаете или ), добавьте следующую строку в тот же файл / etc / systemd / system / mysql. служебный файл исправил это для меня:
Эта последняя проблема, похоже, была исправлена к 16.04, и эта строка больше не требуется, поэтому перед обновлением дистрибутива вы захотите остановить MySQL и удалить строку из файла конфигурации.
84
Matt Raines
10 Окт 2016 в 08:57
С systemd файл override.conf не нужно искать или, возможно, создавать. Просто используйте следующую команду:
Если файл override.conf существует, он читается, в противном случае его можно создать сейчас.
Остальное, как писал Фредерик: Введите LimitNOFILE и перезапустите службы.
3
amalesh
29 Янв 2020 в 11:00
Я предлагаю вам не копировать существующий файл mysql.service, как предлагается, просто создать файл только с теми изменениями, которые вам нужны. Ну действуй:
А содержимое limits.conf просто:
Или какие ограничения вы предпочитаете.
8
Berend de Boer
7 Дек 2016 в 23:18
Начиная с MySQL 5.7.7, это то, что документация рекомендует для Red Hat Enterprise Linux 7, Oracle Linux 7, CentOS 7, SUSE Linux Enterprise Server 12, Fedora 24 и 25:
В Ubuntu 16.04 служба называется mysql, а не mysqld, поэтому я сделал следующее:
Это добавлено в новый файл override.conf:
Затем перезапустили службу:
18
Fredrik
28 Янв 2017 в 06:11
Общие настройки
max_connections=64 — устанавливаем параметр минимальным возможным при необходимости экономить ресурсы сервера, при возникновении в логе записей вида «Too many connections…» увеличиваем значение. Не следует изменять значение этого параметра на старте. 4000 клиентов является максимумом. Можно довести максимальное количество клиентов до 7000, но для стандартных сборок 4000 является пределом.
open_files_limit = 2048 Устанавливать значение стоит опираясь на существующее количество открытых файлов MySQL:
В конфигурационном файле задается большее значение.
connect_timeout (MySQL pre-5.1.23: default 5, MySQL 5.1.23+: default 10) — количество секунд по прошествии которых сервер баз данных будет выдавать ошибку, при активном веб-сервере значение можно уменьшать чтобы увеличить скорость работы, на медленной машине — можно увеличивать. max_connect_errors (default 10) — максимальное количество единовременных соединений с сервером баз данных с хоста запрос блокируется если он прерывается запросами с того же хоста до момента окончания обработки запроса) блокируются навсегда, очистить можно только из командной оболочки MySQL:
В случае атаки на сервер нужно уменьшать (5) чтобы отсекать попытки соединения, при большой активности веб-сервера можно увеличивать max_allowed_packet (default 1M) — максимальный для буфера соединений и буфера результата при исполнении SQL инструкций. Каждый тред имеет свой буфер. Хорошим значением для начала будет 16М. tmp_table_size (system-specific default) — максимальный размер памяти выделяемой под хранение временных таблиц. 16М — довольно много.
Примеры готовых конфигураций для разных объёмов памяти можно посмотреть здесь.
Чтобы посомореть значения переменных можно воспользоваться SQL запросом:
или для конкретных переменных:
Чтобы проверить мониториг InnoDB, используте:
Чтобы узнать, не свопается ли память, используйте команду и смотрите строку swap:
Оптимизация MySQL для MyISAM
Оптимизация параметров MySQL позволяет значительно увеличить производительность MyISAM.
Буферы
Основными параметрами являются key_buffer_size (буфер для работы с ключами и индексами) и sort_buffer (буфер для сортировки).
key_buffer_size = 64M
sort_buffer_size = 32M
|
1 |
key_buffer_size=64M sort_buffer_size=32M |
При наличии 16Гб памяти и более, рекомендуется увеличить key_buffer_size до 128M-256M. Если Вы не используете MyISAM таблицы, рекомендуется установить размер key_buffer_size в 32Мб для хранения индексов временных таблиц.
Кэши
Кэш запросов указывается в опции query_cache_size, ограничение на кэшируемый элемент в query_cache_limit, кэш открытых таблиц в table_open_cache.
table_open_cache = 2048
query_cache_limit = 2M
query_cache_size = 128M
query_cache_type = 1
thread_cache_size = 16
max_heap_table_size = 128M
tmp_table_size = 128M
|
1 |
table_open_cache=2048 query_cache_limit=2M query_cache_size=128M query_cache_type=1 thread_cache_size=16 max_heap_table_size=128M tmp_table_size=128M |
Будьте внимательны при установке завышенного значения query_cache_size, т.к. это может привести к ожиданию блокировок (Be careful not to set the size of the cache too large. Due to the need for threads to lock the cache during updates, you may see lock contention issues with a very large cache). Мы не рекомендуем устанавливать значение больше 256M.
Параметр thread_cache_size указывает количество тредов (threads), уходящих в кеш при отключении клиента. При новом подключении тред не создается, а берется из кеша, что позволяет экономить ресурсы при больших нагрузках. При наличии 32Гб памяти и более рекомендуем увеличить thread_cache_size до 32, table_open_cache в диапазон 4096-8192, query_cache_size до 256M.
Вторичная оптимизация конфига MySQL
Под вторичной оптимизацией я подразумеваю тот тюнинг, который можно произвести только зная профиль нагрузки на БД: соотношение операций чтения и записи, долгие запросы и т.п.
Тюнинг performance_schema в MySQL
Опция performance_schema производит мониторинг всей БД, на что расходуется некоторая часть ресурсов, держать эту опцию постоянно включенной в продакшене крайне не рекомендуется, т.к. может замедлять время выполнения запросов до 25%. Объем потребляемых ресурсов зависит от конфигурации схемы, которую можно посмотреть выполнив запрос:
SHOW VARIABLES LIKE 'performance%';
А если выполнить от имени администратора БД этот запрос:
SHOW ENGINE performance_schema STATUS;
С помощью этого запроса можно понять все ли данные мониторятся, или что-то пропадает:
SHOW STATUS LIKE 'performance%';
Если какой-то счетчик оказался выше ноля, то нужно увеличить соответствующий параметр.
Именно на данных из performance_schema и основана вся фишка MySQLTuner! Чем дольше собираются данные, тем точнее будут рекомендации по оптимизации MySQL и MariaDB. Стоит учесть, что данные performance_schema обнуляются после каждой перезагрузки сервера, поэтому сначала лучше выполнить первичную конфигурацию, после чего оставить сервер под боевой нагрузкой на сутки для последующего анализа.
Работа с данными performance_schema
Переходим в базу данных performance_schema :
USE performance_schema;
И смотрим какие таблицы здесь есть:
SHOW TABLES;
Обратим внимание на наблицы с префиксом setup_, например:
SELECT * FROM setup_consumers; SELECT * FROM setup_instruments;
В них содержатся настройки того, что будет мониториться. С помощью UPDATE можно менять значение колонки ENABLED с NO на YES и наоборот.
Самые горячие таблицы
С помощью этого запроса можно узнать к каким таблицам происходит наибольшее число чтений и записей:
select substring_index(file_name, '/', -1) file_name, event_name, count_read, count_write from file_summary_by_instance where COUNT_READ+COUNT_WRITE > 0 order by COUNT_READ+COUNT_WRITE desc limit 30;
А этим запросом можно узнать статистику по блокировкам:
select event_name, source, sum(timer_wait) timer_wait from events_waits_history_long where event_name not like 'wait/io/file%' group by event_name, source order by 3 desc limit 30;
Решение
Давайте увеличим лимит файловых дескрипторов для mysqld на 10000.
Для начала нужно выяснить систему инициализации в нашем Linux дистрибутиве, выполняем:
strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit)/) { print toupper(substr($0, RSTART, RLENGTH));exit; }'
Команда выдала SYSTEMD.
Для systemd лимиты устанавливаются немного по другому, чем принято думать, а именно:
Выясним где находится unit файл для запуска MySQL:
# systemctl status mysql
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: active (running) since Пт 2018-04-27 06:01:36 +05; 6h ago
Main PID: 6370 (mysqld)
Tasks: 82
Memory: 88.2G
CPU: 1d 19h 2min 53.203s
CGroup: /system.slice/mysql.service
└─6370 /usr/sbin/mysqld
Создадим файл с описанием новых лимитов:
Мы выяснили, что unit файл это /lib/systemd/system/mysql.service, теперь нам нужно создать каталог /lib/systemd/system/mysql.service.d и в нем разместить файл limit.conf со следующим содержимым:
LimitNOFILE=10000
Выполним несколько команд для этого:
mysql_systemd_dir="/lib/systemd/system/mysql.service.d"
mkdir -p ${mysql_systemd_dir}
echo "" >${mysql_systemd_dir}/limit.conf
echo "LimitNOFILE=10000" >>${mysql_systemd_dir}/limit.conf
systemctl daemon-reload
Теперь проверим будет ли наша конфигурация подхвачена:
# systemctl status mysql
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/mysql.service.d
└─limit.conf
Active: active (running) since Пт 2018-04-27 06:01:36 +05; 6h ago
Main PID: 6370 (mysqld)
Tasks: 82
Memory: 88.2G
CPU: 1d 19h 2min 53.203s
CGroup: /system.slice/mysql.service
└─6370 /usr/sbin/mysqld
Отлично, теперь нам нужно перезапустить MySQL:
systemctl restart mysql
Проверим настройки MySQL:
# mysql -u root -p mysql> show global variables like '%max_connections%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 300 | +-----------------+-------+ 1 row in set (0,00 sec) mysql> show global variables like '%open_files_limit%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | open_files_limit | 10000 | +------------------+-------+ 1 row in set (0,00 sec) mysql> show global variables like '%table_open_cache'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | table_open_cache | 16000 | +------------------+-------+ 1 row in set (0,00 sec)
Увеличение числа открытых файлов
В большинстве Linix-систем по умолчанию лимит открытия файловых дескрипторов установлен в 1024, для работы этого недостаточно.
Проверим текущие опции:
ulimit -n
| 1 | ulimit-n |
Внесем требуемые лимиты в
* hard nofile 35000
* soft nofile 35000
root hard nofile 35000
root soft nofile 35000
|
1 |
*hard nofile35000 *soft nofile35000 root hard nofile35000 root soft nofile35000 |
Динамически изменим текущие лимиты:
ulimit -n 35000
| 1 | ulimit-n35000 |
Проверим soft limit:
ulimit -Sn
| 1 | ulimit-Sn |
и hard limit
ulimit -Hn
| 1 | ulimit-Hn |
Текущие лимиты в MySQL проверим SQL-запросом:
SHOW VARIABLES LIKE ‘%open_files%’
| 1 | SHOW VARIABLES LIKE’%open_files%’ |
innodb_open_files 2048
open_files_limit 35000
|
1 |
innodb_open_files2048 open_files_limit35000 |
Увеличить Max Open File Limit в Unix/Linux
Приведу команды на различные Unix/Linux ОС
Увеличить Max Open File Limit в Linux
Для начала проверим какой предел установлен в ОС:
# cat /proc/sys/fs/file-max
Увеличиваем данный предел в Linux
Мы можем увеличить лимиты для открытых файлов:
- Временно.
- Постоянно.
-===ВРЕМЕННО===-
Если есть необходимость увеличить лимит временно (для тестирования, например), то можно это сделать так:
# sysctl -w fs.file-max=500000
Или:
# echo "500000" > /proc/sys/fs/file-max
Вот еще один пример:
# ulimit -n 65635
-===ПОСТОЯННО===-
Если есть необходимость увеличить лимит навсегда, то можно это сделать так:
# vim /etc/sysctl.conf fs.file-max = 500000
Эти настройки будут сохраняться даже после перезагрузки системы. После добавления конфигурации в файл, выполните следующую команду, чтобы изменения вступили в силу:
# sysctl -p
Настройка лимитов для каждого пользователя
# vim /etc/security/limits.conf
Добавляем параметры:
* hard nofile 500000 * soft nofile 500000 root hard nofile 500000 root soft nofile 500000
Проверка установленных лимитов
Используйте следующую команду, чтобы увидеть максимальное чисто для открытых файлов:
# cat /proc/sys/fs/file-max
Подключаемся от пользователя (у меня это nginx):
# su nginx
Проверяем параметры Hard лимитов:
# ulimit -Hn
В консоле, можно ввести данную команду (очень удобно отображает):
# for pid in `pidof nginx`; do echo "$(< /proc/$pid/cmdline)"; egrep 'files|Limit' /proc/$pid/limits; echo "Currently open files: $(ls -1 /proc/$pid/fd | wc -l)"; echo; done
Проверяем параметры лимитов Soft:
# ulimit -Sn
Увеличить Max Open File Limit в Mac OS X
Выполним проверку лимитов с помощью:
$ launchctl limit maxfiles
Где:
- Первый аргумент — soft limit.
- Второй аргумент — hard limit.
Можно прописать в файл:
# vim ~/.bash_profile
Следующее значение:
ulimit -n 65536 200000
Вот и все!
Увеличюем nginx worker_rlimit_nofile в nginx ( на уровне Nginx)
В nginx также можно увеличить лимиты с директивой worker_rlimit_nofile, которая позволяет увеличить этот лимит, если это не хватает данного ресурса на лету на уровне процесса:
# vim /etc/nginx/nginx.conf
И прописываем (редактируем):
# set open fd limit to 30000 worker_rlimit_nofile 30000;
После чего, проверяем конфигурацию nginx и перезапускаем его:
Save and close the file. Reload nginx web server, enter:
# nginx -t && service nginx -s reload
ulimit в Kali Linux
Включение ограничений на основе PAM в Unix/Lixux
Для Debian/Ubuntu
Редактируем файл (Debian/Ubuntu):
# vim /etc/pam.d/common-session
Вставляем:
session required pam_limits.so
Открываем еще один файл:
# vim /etc/security/limits.conf
Прописываем лимиты:
* soft nofile 65536 * hard nofile 200000
Открываем:
# vim /etc/ssh/sshd_config
И, приводим к виду:
UseLogin yes
И выполняем рестарт:
# reboot
Для CentOS/RedHat/Fedora
Редактируем файл (Debian/Ubuntu):
# vim /etc/pam.d/login
Вставляем:
session required pam_limits.so
Открываем еще один файл:
# vim /etc/security/limits.conf
Прописываем лимиты:
* soft nofile 65536 * hard nofile 200000
Открываем:
# vim /etc/ssh/sshd_config
И, приводим к виду:
UseLogin yes
И выполняем рестарт:
# reboot
У меня все! Статья «Увеличить Max Open File Limit в Unix/Linux», завершено.
Разбор параметров тюнинга Mysql
Разберёмся по порядку с каждым параметром настройки и вопросами которые есть при этом. Итак по пунктам.
key_buffer = 2Gkey_buffer_size = 4G
Так и не смог я понять, различаются ли эти два параметра или первый является устаревшим значением второго.
max_connections = 500 и thread-cache-size = 500
По замерам выходило, что не более 90 одновременных подключений, так и поставил 500 с запасом. Тут следует учесть что следующий параметр thread-cache-size должен быть одинаковым числом с максимальным соединением. Поэтому там также стоит 500.
table-cache = 120000 и table-open-cache = 120000
Здесь я поставил по 120000, так как таблиц у меня достаточно много, если у вас не много сайтов, то этот параметр можно не повышать.
interactive-timeout = 360
Установил в 360, чтобы снимались запросы, которые находятся без активности 6 минут или 360 секунд.
query_cache_limit = 12Mquery_cache_size = 4Gjoin_buffer_size = 512M
Следующие три параметра настроил исходя из следующих наблюдений. Пробовал ставить query_cache_size от 2 до 6 гигабайт, в итоге оптимально показалось 4. Обработка запросов до 12 мегабайт мне вполне хватало, поэтому оставил 12. Но есть такое мнение, что большой query_cache_size на самом деле сильно грузит систему и желательно держать кеш в memcashed, на практике я не заметил особо, чтобы он забирал мощность, а вот при проверке кеша, обнаружил, что много запросов проходит через него.
sort_buffer_size = 1Gread_buffer_size = 1Gread_rnd_buffer_size = 2G
Буфера поставил побольше, так как несколько баз имеют большой размер, хотя есть риск переполнения памяти, тем не менее они настолько не забивали память.
