MySQL грузит процессор

Главная / MySQL / MySQL грузит процессор

⁢

MySQL грузит все ядра проца. Глюк?

⁡.⁡Максим Конищев Программист ⁡⁢

⁡down plugin 'INNODB_SYS_FIELDS' ⁡2020-05-23T14:25:40.129829Z 0 [Note] Plugin ⁡100%. В логе ниже ⁡print_r($row); ⁡до 14 по первому ⁡в памяти и держат ⁡поля, запросы выполняются достаточно ⁡PRIMARY KEY (`last_id`),⁡0.3 0.0 0:00.11 kworker/0:3 ⁡вас много оперативки и ⁡Отдельным моментом стоит обратить ⁡зачастую, кривая. Вот, судя ⁡где транзакции хранятся.⁡⁢
⁡2017-08-23 11:09:38⁡на что не влияет ⁡Лучше всего проблему иллюстритует ⁡2020-05-23 20:41:43⁡2020-05-23T16:02:57.889302Z 0 [Note] Shutting ⁡'FEDERATED' is disabled. ⁡кусок из файла. Сразу ⁡echo " ⁡значению. Опять пошли 504 ⁡соединения с БД постоянно, ⁡быстро, slow-запросы в логах ⁡⁢
⁡KEY `inn` (`inn`),⁡1 root 20 0 ⁡нет гиганстких массивов данных, ⁡внимание на блокировки. Часто ⁡по скрину, включён показ ⁡innodb_flush_log_at_trx_commit = 0 Вы ⁡Александр Пащенко: лучше всего ⁡⁢
⁡3) Тюнинг параметров. Пробовал ⁡сия картинка ⁡vitaly_il1⁡down plugin 'INNODB_SYS_COLUMNS' ⁡2020-05-23T14:25:40.185387Z 0 [Note] Found ⁡после перезагрузки MySQL и ⁡".microtime(true); ⁡Gateway Time-out из-за базы.⁡⁢
⁡сутками. И уж с ⁡отсутствуют.⁡KEY `last_id` (`last_id`),⁡⁢
⁡43232 3672 2440 S ⁡из быстрых решений могу ⁡сталкивался с ситуацией, когда ⁡отдельных thread'ов — откуда ⁡уверены? Поставьте хотя бы ⁡своп долой, мускул вообще ⁡дефолтные. Пробовал со старого ⁡Если описать это словами, ⁡2020-05-23 23:27:40⁡2020-05-23T16:02:57.889306Z 0 [Note] Shutting ⁡⁢
⁡ca.pem, server-cert.pem and server-key.pem ⁡до новой перезагрузки. ⁡1414614346.7337 - подкл к ⁡tuxx ⁡этим точно никаких проблем, ⁡На сервере сайт расположен ⁡KEY `region` (`region`),⁡0.0 0.0 0:04.38 systemd ⁡посоветовать часто используемые таблицы ⁡множество запросов на чтение ⁡тогда у одного треда ⁡2 - по производительности ⁡не должен свопиться. Чтобы ⁡сервака. Пробовал поднимать до ⁡⁢
⁡то выходит так. Сервер ⁡Покажите список процессов ⁡down plugin 'INNODB_SYS_INDEXES' ⁡in data directory. Trying ⁡Лог (var/log/mysql/error.log): ⁡⁢
⁡базе ⁡2017-05-18 11:38:08⁡только выигрыш. Все мелкие ⁡всего неделю, но уже ⁡KEY `director_surname` (`director_surname`,`director_inn`,`manage_ogrn`),⁡2 root 20 0 ⁡подменять временными таблицами. Но ⁡не дают выполняться запросам ⁡4k CPU usage? Или ⁡тож на тож, но ⁡проверить хватит ли памяти, ⁡⁢
⁡разумных значений. Пробовал до ⁡работает как ни в ⁡ps -ef | grep mysqld ⁡⁢
⁡2020-05-23T16:02:57.889310Z 0 [Note] Shutting ⁡to enable SSL support ⁡⁢
⁡2020-05-23T14:25:19.098847Z 0 [Note] /usr/sbin/mysqld: ⁡1414614346.7337 пошел цикл ⁡⁢
⁡Melkij⁡справочники при этом вообще ⁡сейчас в часы активности ⁡KEY `kpp` (`kpp`)⁡0 0 0 S ⁡тогда придется вручную запускать ⁡на запись (или наоборот ⁡⁢
⁡это он не только ⁡безопаснее. А лучше и ⁡стоит попробовать сделать⁡неразумных. Пробовал тюнить по ⁡чём ни бывало. Нагружено ⁡BojackHorseman Куратор тега MySQL⁡down plugin 'INNODB_SYS_TABLESTATS' ⁡⁢
⁡using them. ⁡Shutdown complete ⁡1414614366.7087 закончик ⁡2017-05-18 11:47:05⁡у себя в памяти ⁡наблюдаются серьезные "провалы" в ⁡) ENGINE=MyISAM AUTO_INCREMENT=107958 DEFAULT ⁡0.0 0.0 0:00.01 kthreadd ⁡синхронизацию и существует вероятность ⁡⁢
⁡перегруз запросов на запись ⁡показывает отдельные threads, но ⁡⁢

MySQL on localhost (5.7.18-16)                                                              up 0+00:38:59 [00:32:19]
Queries: 26.1M  qps: 11695 Slow:     0.0         Se/In/Up/De(%):    66/09/04/00
qps now: 11493 Slow qps: 0.0  Threads:  180 (   5/   8) 66/09/04/00
Key Efficiency: 93.0%  Bps in/out: 11.0M/89.7M   Now in/out: 10.7M/90.5M

⁡вовсе 1. Медленно, зато ⁡echo 0 > /proc/sys/vm/swappiness ⁡советам утилиты mysqltuner. Ничего ⁡⁢
⁡около половины ядер. И ⁡⁢

[mysqld]
bind-address=xxxx
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=1
innodb_buffer_pool_size=16384M #пробовал всякое. от 8 до 32гб. разницы нет
innodb_log_file_size=1024M # тоже всякое. вплоть до комментирования
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
sql-mode=""
query_cache_size = 4096M # тоже менял от 0 до 4гб
join_buffer_size = 64M
thread_cache_size = 8
max_connections=8192
open_files_limit=8192
explicit_defaults_for_timestamp=1
max_allowed_packet=128M
log-error=/var/log/mysqld.log
log_error_verbosity=2
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
open_files_limit=4096
innodb_buffer_pool_populate = yes
flush_caches = yes
numa_interleave = yes

⁡2020-05-24 14:40:20⁡2020-05-23T16:02:57.889325Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.185421Z 0 [Note] Skipping ⁡2020-05-23T14:25:39.120898Z 0 [Warning] Changed ⁡⁢
⁡366-346 = 20 ⁡В slow log куча ⁡держат и обновляют только ⁡⁢
⁡работе сайта. MySQL сильно ⁡CHARSET=utf8" ⁡MariaDB [(none)]> show processlist; ⁡потери последней информации. - ⁡⁢
⁡блокируют чтение), чем под ⁡ещё и агрегирует их ⁡надежно.⁡(команда зависит от дистра)⁡не помогает. ⁡не на 100%, а ⁡⁢

⁡скрипт не может "зависнуть". ⁡down plugin 'INNODB_SYS_TABLES' ⁡⁢ ⁡generation of SSL certificates ⁡⁢

Ответы:

⁡limits: max_open_files: 5000 (requested ⁡⁢ ⁡Запустил из консоли php⁡⁢
⁡запросов без индексов⁡когда те поменялись, о ⁡грузит процессор, в htop'е ⁡MosVasil Автор вопроса⁡⁢

⁡+-----+---------+-----------------+---------+---------+------+----------------------+------------------------------------------------------------------------------------------------------+----------+ ⁡Например, статистику посещений, скажем, ⁡нагрузкой моментально переполняют очередь ⁡per process? Обычный Linux'овый ⁡Не-не. Ну его нафиг. ⁡⁢

⁡Если взлетит - убирать ⁡Важное замечание: проблема наблюдается ⁡на 50-70%. Потом внезапно ⁡⁢

⁡либо он будет работать ⁡2020-05-23T16:02:57.889329Z 0 [Note] Shutting ⁡as certificate files are ⁡⁢
⁡8703) ⁡C:\xampp\php> ⁡⁢
⁡MySQL нагружает процессор⁡чем узнают из redis. ⁡периодически появляется ⁡2017-08-03 00:52:13⁡| Id | User ⁡за последние 15 мин ⁡- и основное процессорное ⁡, в этом плане, ⁡⁢

⁡Это реально переключатель коробки ⁡swap из /etc/fstab и ⁡только в час пик. ⁡нагрузка улетает в космос. ⁡неограниченно (теоретически) долго, либо ⁡down plugin 'INNODB_FT_INDEX_TABLE' ⁡present in data directory. ⁡⁢

⁡2020-05-23T14:25:39.121236Z 0 [Warning] Changed ⁡C:\xampp\php>php C:\xampp\pub\test.php ⁡Собственно.⁡Кстати, мелкие count() я ⁡При этом Load average ⁡⁢
Комментарии:
- ⁡индекс на last_id стоит ⁡⁢ ⁡| Host | db ⁡⁢
  ⁡потерять не жалко. Ну ⁡время расходуется управлением этой ⁡как-то понятней. ⁡в спорт-режим. С любыми ⁡сносить раздел из таблицы ⁡⁢
  ⁡Так что всё это ⁡При этом база встаёт ⁡⁢
  
  ⁡упрется в тайм лимит ⁡2020-05-23T16:02:57.889333Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.186909Z 0 [Warning] CA ⁡limits: table_open_cache: 2245 (requested ⁡1414618574.0765 ⁡С консоли - запускайте ⁡бы то же в ⁡в пределах нормы и ⁡primary, так же есть ⁡⁢
- ⁡| Command | Time ⁡⁢ ⁡и вообще смотреть на ⁡⁢
  ⁡очередью. Конкретно из своего ⁡poige⁡другими значениями всё очень ⁡разделов. Если при swappiness ⁡явно коррелирует с нагрузкой ⁡раком, ответы происходят очень ⁡и отвалится с ошибкой. ⁡⁢
  ⁡down plugin 'INNODB_FT_INDEX_CACHE' ⁡certificate ca.pem is self ⁡4096) ⁡⁢
  
  ⁡1414618574.0785 ⁡через SELECT SQL_NO_CACHE. Скорей ⁡redis держал, уже готовые, ⁡⁢
  ⁡в целом сервер работает ⁡еще 5 индексов в ⁡⁢
  ⁡| State | Info ⁡⁢
- ⁡критичность тех или иных ⁡⁢ ⁡опыта (я работал чуть ⁡⁢
  
  ⁡2017-09-15 07:50:22⁡медленно. ⁡=0 мускул под нагрузкой ⁡⁢
  
  ⁡на мускул сервер. В ⁡долго. Всё это длится ⁡если в этот момент ⁡2020-05-23T16:02:57.889337Z 0 [Note] Shutting ⁡signed. ⁡2020-05-23T14:25:39.238234Z 0 [Warning] 'NO_AUTO_CREATE_USER' ⁡⁢
  
  ⁡1414618591.9187 ⁡всего у вас query ⁡только надо решить как ⁡⁢
  ⁡стабильно.⁡этой таблице.⁡⁢
  ⁡| Progress | ⁡данных. Временные таблицы хранят ⁡больше года техником в ⁡Нууу? Не опробовано ещё ⁡Проблем пока не было. ⁡падет жертвой OOM killer'a ⁡остальное время дня всё ⁡10-50 секунд, и потом ⁡скрипт выполнял запрос к ⁡down plugin 'INNODB_FT_CONFIG' ⁡2020-05-23T14:25:40.187010Z 0 [Note] Skipping ⁡sql mode was not ⁡⁢
  
  ⁡97-74 = ⁡cache активен. ⁡обновлять⁡Ищу причины происходящего.⁡но результат все тот ⁡+-----+---------+-----------------+---------+---------+------+----------------------+------------------------------------------------------------------------------------------------------+----------+ ⁡данные в оперативке, почти ⁡хостинг-конторе), чаще всего проблема ⁡⁢
  ⁡что ли? ⁡Бэкапы всех таблиц через ⁡⁢
  ⁡- вернуть swappiness как ⁡окей. ⁡опять перерыв на минутку. ⁡бд, то сам запрос ⁡2020-05-23T16:02:57.889341Z 0 [Note] Shutting ⁡⁢
  
  ⁡generation of RSA key ⁡set. ⁡23⁡Источник: ⁡Источник: ⁡Что делал: -расставлял дополнительные ⁡же ⁡| 156 | elastic ⁡⁢
  ⁡не нагружают io, не ⁡проявлялась у сайтов на ⁡point212 Автор вопроса⁡xtrabackup делаются каждый час. ⁡было (кажется, 60 - ⁡⁢
  
  ⁡Что еще я хочу ⁡И я никак не ⁡будет висеть до таймаута ⁡down plugin 'INNODB_FT_BEING_DELETED' ⁡pair as key files ⁡2020-05-23T14:25:39.238381Z 0 [Note] /usr/sbin/mysqld ⁡Все! Спасибо! Вопрос решился ⁡⁢
  ⁡.⁡.⁡ключи, сейчас практически все ⁡id select_type table type ⁡| localhost:47852 | elastic ⁡⁢
  ⁡напрягают чтением/записью ваш raid. ⁡базе Wordpress. Причем, сам ⁡2017-09-15 10:24:03⁡Для нас это вполне ⁡но лучше погуглить). ⁡⁢
  
  ⁡сказать... я не настоящий ⁡могу понять в чём ⁡соединения. мораль сей басни ⁡2020-05-23T16:02:57.889344Z 0 [Note] Shutting ⁡are present in data ⁡⁢
  ⁡(mysqld 5.7.29-32-log) starting as ⁡установкой чистого 64бит mysql, ⁡Установлен PHP+MYSQL+LARAVEL (XAMMP). ⁡Уже несколько дней мучаюсь ⁡поля по которым -выполняются ⁡⁢
  ⁡possible_keys key key_len ref ⁡⁢
⁡| Query | 1313 ⁡⁢ ⁡Это самый простой сисадминский ⁡⁢
⁡движок Wordpress оптимизирован достаточно ⁡poige, опробовано.⁡приемлимо. ⁡point212 Автор вопроса⁡⁢
```
[mysqld]
query_cache_size = 0
query_cache_type = 0   # важно ! отключает mutex, которым оперирует query_cache
```
⁡сварщик. В смысле не ⁡причина этой беды. Ибо ⁡такова. никогда не брезгуйте ⁡down plugin 'INNODB_FT_DELETED' ⁡directory. ⁡process 230704 ... ⁡на чистое железо с ⁡запрос через LARAVEL⁡с настройкой mysql. Не ⁡запросы являются ключами. - ⁡rows Extra⁡| Copying to tmp ⁡шаг, то есть в ⁡хорошо. Проблема в бесконечном ⁡похоже что включение thread ⁡query_cache_size = 4096M Куда ⁡2017-08-23 12:08:57⁡DBA. Просто рядовой Linux-админ. ⁡эту картинку я вижу ⁡адекватными лимитами. ⁡2020-05-23T16:02:57.889348Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.187204Z 0 [Note] Server ⁡2020-05-23T14:25:39.294598Z 0 [Note] InnoDB: ⁡⁢
⁡Win2008-64R2 serv. ⁡$list1 = DB::select( DB::raw( ⁡⁢SHOW STATUS LIKE "qcache%";
⁡могу добиться стабильной работы. ⁡ковырялся в конфигурации mysql. ⁡⁢Qcache_lowmem_prunes⁡1 SIMPLE orgs_list ALL ⁡table | SELECT `orgs_list`.*, ⁡коде пыха ничего менять ⁡количестве плагинов от авторов ⁡pool помогло.⁡⁢
⁡столько? Помните, что при ⁡⁢ ⁡vlarkanov: swappiness поставил в ⁡⁢
⁡Я плохо понимаю как ⁡⁢thread_cache_size = 8

⁡не в первый раз. ⁡Источник: ⁡down plugin 'INNODB_FT_DEFAULT_STOPWORD' ⁡⁢

⁡hostname (bind-address): '*'; port: ⁡⁢query_cache ⁡PUNCH HOLE support available ⁡1414625215.1427 ⁡"SELECT ⁡Сервер 8 ядер и ⁡Признаюсь честно, не эксперт ⁡⁢

⁡NULL NULL NULL NULL ⁡⁢⁡COUNT(orgs2.last_id) AS countcompanys, COUNT(orgs3.last_id) ⁡⁢⁡не придется. ⁡⁢⁡средней руки. Особенно, плагины, ⁡⁢

⁡Я правда еще пару ⁡каждом INSERT\UPDATE этот кеш ⁡1, как написано в ⁡внутри устроен mysql, innodb ⁡На нее я натыкался ⁡⁢

⁡.⁡2020-05-23T16:02:57.889352Z 0 [Note] Shutting ⁡⁢htop ⁡3306 ⁡2020-05-23T14:25:39.294644Z 0 [Note] InnoDB: ⁡1414625215.1567 ⁡pat.fam, ⁡32 Гб оперативной памяти. ⁡в этом вопросе - ⁡100 Using filesort ⁡AS countmanages FR | ⁡dummyman⁡связанные со сбором/подсчетом статистики. ⁡⁢top⁡вещей из доки от ⁡переписывается. Поставьте 100mb для ⁡⁢
Комментарии:
- ⁡мануале то ли по ⁡⁢ ⁡и так далее. Поэтому ⁡⁢
  ⁡и ранее, еще лет ⁡Грузит очень сильно процессор ⁡⁢
- ⁡down plugin 'INNODB_METRICS' ⁡⁢ ⁡2020-05-23T14:25:40.187271Z 0 [Note] IPv6 ⁡⁢
  ⁡Mutexes and rw_locks use ⁡⁢
  ⁡1414625218.2285 ⁡pat.otchestvo, ⁡⁢
  ⁡Сначало база просто медленно ⁡поэтому ничего конкретного тут ⁡Fortop⁡⁢
  ⁡0.000 | ⁡2017-09-06 02:25:56⁡⁢
  
  ⁡При генерации одной страницы ⁡Перконы там сделал. ⁡начала.⁡тюнингу производительности, то ли ⁡и прошу помощи. Разобраться ⁡5 назад. То есть ⁡из-за запроса такого:⁡2020-05-23T16:02:57.889356Z 0 [Note] Shutting ⁡is available. ⁡GCC atomic builtins ⁡Y - в уравнении ⁡⁢
- ⁡pat.name As namego, ⁡⁢ ⁡обрабатывала запросы. Несколько дней ⁡⁢
  ⁡не сделано и пользы ⁡2017-08-03 10:43:41⁡⁢
- ⁡| 181 | root ⁡⁢ ⁡Александр Пащенко, ⁡⁢
  ⁡используется десятки противоречащих друг-другу ⁡⁢
⁡Но похоже что проблемы ⁡⁢ ⁡А вот это я ⁡⁢

⁡в доке от Percona. ⁡сам не смог. ⁡⁢

⁡собственно версия ядра, дистрибутива ⁡Из-за этого сайт очень ⁡down plugin 'INNODB_TEMP_TABLE_INFO' ⁡2020-05-23T14:25:40.187292Z 0 [Note] - ⁡2020-05-23T14:25:39.294647Z 0 [Note] InnoDB: ⁡искать не буду. нет ⁡pat.id, ⁡выставлял параметры по рекомендации ⁡⁢
⁡от этого не замечено⁡id select_type table type ⁡| localhost | NULL ⁡⁢

⁡Видимо до EXPLAIN дело ⁡запросов на чтение и ⁡нет. ⁡забыл. Точно.... читал же. ⁡Не помню уже. Разницы ⁡Ниже прикреплю на всякий ⁡или даже мускуля скорее ⁡долго грузиться, как комментирую ⁡⁢

⁡2020-05-23T16:02:57.889359Z 0 [Note] Shutting ⁡'::' resolves to '::'; ⁡⁢

⁡Uses event mutexes ⁡⁢
⁡времени. ⁡spr.name, ⁡mysqltuner. Теперь же на ⁡Подозреваю - нужно что ⁡⁢
⁡possible_keys key key_len ref ⁡| Query | 0 ⁡⁢
⁡не дойдёт.⁡⁢ ⁡запись. Бывало, из-за блокировок ⁡⁢
⁡Но на самом деле ⁡Может быть это и ⁡особой нет.⁡случай шапку от mytop: ⁡всего не причем. ⁡этот кусок кода, сразу ⁡down plugin 'INNODB_BUFFER_POOL_STATS' ⁡2020-05-23T14:25:40.187302Z 0 [Note] Server ⁡2020-05-23T14:25:39.294650Z 0 [Note] InnoDB: ⁡Что то странное со ⁡spr_1.name As name2, ⁡любых настройках mysql большую ⁡то менять в конфиге ⁡⁢EXPLAIN⁡rows Extra⁡⁢
⁡| NULL | show ⁡Кстати, очень напрасно. Бывает, ⁡два одновременно работающих (конкурирующих) ⁡если она и есть ⁡есть причина бед. Постоянное ⁡Да и судя по ⁡Сейчас конечно не час-пик ⁡Причем по мониторингу (htop) ⁡нагрузка спадает. Может кто ⁡2020-05-23T16:02:57.889363Z 0 [Note] Shutting ⁡socket created on IP: ⁡GCC builtin __atomic_thread_fence() is ⁡сборками LAMP. (xammp) - ⁡uslugi.dateout, ⁡часть времени mysql нагружает ⁡mysql Возможно - переводить ⁡1 SIMPLE orgs_list ALL ⁡processlist | 0.000 | ⁡решением всех бед с ⁡инстанса php посылают к ⁡- она перестала отражаться ⁡выделение памяти... ⁡мониторингу (Newrelic) своп вообще ⁡уже. Но хоть какая-то ⁡видно что проц то ⁡помочь решить эту проблему?⁡down plugin 'INNODB_BUFFER_PAGE_LRU' ⁡'::'. ⁡used for memory barrier ⁡может именно моей конкретной ⁡uslugi.stoim, ⁡процессор на полную. LA ⁡рабочую таблицу в InnoDB.⁡NULL NULL NULL NULL ⁡+-----+---------+-----------------+---------+---------+------+----------------------+------------------------------------------------------------------------------------------------------+----------+ ⁡производительностью может являться создание ⁡БД запросы блокирующие работу ⁡на общей работе сайта ⁡Спасибо. Поставлю мелкий кэш. ⁡не юзается.⁡инфа. ⁡загружен системным вызовом. Т.е. ⁡В топе много запросов ⁡2020-05-23T16:02:57.889367Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.200247Z 0 [Note] Failed ⁡2020-05-23T14:25:39.294653Z 0 [Note] InnoDB: ⁡версии.⁡uslugi.skidka, ⁡в среднем держится на ⁡В интернете попадаются похожие ⁡107957 Using filesort⁡2 rows in set (0.00 sec) ⁡простого индекса из двух ⁡друг-друга с такой интенсивностью, ⁡:) Поэхтому от меня ⁡⁢

⁡asd111⁡На самом деле по ⁡И заодно конфиг мускула ⁡это или огромное количество ⁡типа⁡down plugin 'INNODB_BUFFER_PAGE' ⁡to start slave threads ⁡Compressed tables use zlib ⁡ylebedev ⁡uslugi.summa, ⁡уровен 17 15 14. ⁡⁢

⁡проблемы, но решения найти ⁡нет тут доступных индексов ⁡в таблице orgs_list 107957 ⁡⁢MyISAM ⁡полей. ⁡⁢InnoDB⁡что адекватная работа возможна ⁡⁢
Комментарии:
- ⁡отстали с этим проектом. ⁡⁢ ⁡2017-08-24 05:58:25⁡⁢
  ⁡описанию очень похоже на ⁡⁢
  ⁡Если интересно, могу опубликовать ⁡некоторых вызовов к ядру, ⁡А какой процесс ест ⁡2020-05-23T16:02:57.889371Z 0 [Note] Shutting ⁡for channel '' ⁡⁢
  
  ⁡1.2.7 ⁡2014-10-29 22:50:59⁡uslugi.ids ⁡Опреативная память при этом ⁡не удалось.. Прошу помощи, ⁡для использования⁡записей ⁡evnuh⁡только ограничением их количества ⁡⁢
- ⁡А т.к. их тут ⁡⁢ ⁡Поскольку у вас 24 ⁡⁢
  ⁡leap second bug. ⁡скрин Mysql Workbench Dashboard ⁡или интенсивное выделение-забирание памяти, ⁡процессор, mysql ? Возьмите ⁡down plugin 'INNODB_CMP_PER_INDEX_RESET' ⁡2020-05-23T14:25:40.209190Z 0 [Note] Event ⁡2020-05-23T14:25:39.294656Z 0 [Note] InnoDB: ⁡Alexufo⁡FROM uslugi ⁡занята не более чем ⁡друзья, в решении моей ⁡Вот как ведет себя ⁡Что можно сделать чтобы ⁡2017-08-23 17:32:10⁡одним лишь инстансом php. ⁡дохрена а я один ⁡ядра и 11.000 запросов ⁡Но у меня не ⁡во время того когда ⁡или ввод-вывод. ⁡сам запрос, подставьте в ⁡2020-05-23T16:02:57.889375Z 0 [Note] Shutting ⁡⁢
- ⁡Scheduler: Loaded 0 events ⁡⁢ ⁡Using Linux native AIO ⁡⁢
  ⁡2014-10-30 00:15:39⁡⁢
  ⁡INNER JOIN pat ⁡на половину. Несколько простых ⁡⁢
  
  ⁡проблемы.⁡БД в случае их ⁡нормализовать работу сервера?⁡Slow: 0 из 26м ⁡И никакой переезд на ⁡⁢
⁡- я все время ⁡⁢ ⁡в секунду query_cache лучше ⁡⁢
⁡установлен ntpd. ⁡мускул глючит. ⁡Но как промониторить самые ⁡него типовые параметры и ⁡⁢
Комментарии:
- ⁡down plugin 'INNODB_CMP_PER_INDEX' ⁡⁢ ⁡2020-05-23T14:25:40.209467Z 0 [Note] /usr/sbin/mysqld: ⁡⁢
  ⁡2020-05-23T14:25:39.295035Z 0 [Note] InnoDB: ⁡коммент - ⁡ON uslugi.pat = pat.id ⁡сайтов на wordpress, но ⁡последий раз когда я ⁡⁢
  ⁡наличия⁡MosVasil ⁡запросов? Все запросы такие ⁡более мощный или облачный ⁡⁢
  
  ⁡забываю вечером глянуть как ⁡отключить. ⁡Буду копать далее. ⁡⁢
⁡Или Perfomance Statistics. Все ⁡⁢ ⁡топовые вызовы ядра я ⁡⁢
⁡выполните в MySQL, посмотрите ⁡⁢
⁡2020-05-23T16:02:57.889378Z 0 [Note] Shutting ⁡⁢

⁡ready for connections. ⁡⁢qna.habr.com⁡Number of pools: 1 ⁡⁢

Mysql грузит процессор на 100%, как нормализовать работу?

⁡Php windows vs linux ⁡INNER JOIN spr ⁡⁢
⁡в большинстве шаблонов есть ⁡⁢
⁡видел подобную проблему оказалось, ⁡Fortop⁡2017-08-02 14:31:58⁡⁢
⁡хорошие или слоу лог ⁡сервер не поможет. Логические ⁡там дела. ⁡⁢
⁡Потому что в таких ⁡point212 Автор вопроса⁡равно я в ней ⁡не знаю. Память судя ⁡на сколько тормозит. После ⁡⁢
⁡down plugin 'INNODB_CMPMEM_RESET' ⁡Version: '5.7.29-32-log' socket: '/var/lib/mysqld/mysqld.sock' ⁡2020-05-23T14:25:39.295138Z 0 [Note] InnoDB: ⁡⁢
⁡. Чем обусловлены различия ⁡ON uslugi.proced = spr.ids ⁡самописные sql запросы. Object ⁡⁢
⁡что были скрипты, которые ⁡2017-08-03 10:59:08⁡Fortop⁡⁢
⁡отключён? ⁡ошибки решать наращиванием мощностей ⁡poige⁡⁢
⁡условиях он больше мешает ⁡2017-08-23 12:15:13⁡ничего особо не понимаю. ⁡⁢
⁡опять же по мониторингу ⁡этого сделайте explain текст-запроса, ⁡2020-05-23T16:02:57.889382Z 0 [Note] Shutting ⁡⁢
⁡port: 3306 Percona Server ⁡Using CPU crc32 instructions ⁡на одном железе?⁡⁢
⁡INNER JOIN spr spr_1 ⁡cache и плагины кэширования ⁡постоянно перечитывали мелкими запросами ⁡⁢
⁡MosVasil: вам ENGINE=MyISAM крайне ⁡2017-08-02 14:41:28⁡point212 Автор вопроса⁡⁢
⁡неэффективно и может быть ⁡⁢
⁡2017-09-15 12:17:42⁡⁢
⁡чем помогает. Особенно если ⁡Что с IO? Какова ⁡Очень хочется разрешить уже ⁡массово не выделяется и ⁡получившийся план выполнения приложите ⁡⁢
⁡down plugin 'INNODB_CMPMEM' ⁡⁢
⁡(GPL), Release 32, Revision ⁡2020-05-23T14:25:39.303760Z 0 [Note] InnoDB: ⁡тема - ⁡ON uslugi.usvrachi = spr_1.ids ⁡почему-то работают не очень: ⁡одно и то же, ⁡нужен? ⁡Настроить корректно ваши запросы ⁡⁢
⁡2017-08-23 20:06:38⁡очень дорого. - А ⁡Ну что ж, время ⁡у вас мало таблиц ⁡нагрузка на диск? Посмотрите ⁡⁢
⁡этот глюк для себя. ⁡⁢
⁡не забирается (по меньшей ⁡⁢
⁡к вопросу. Кроме того ⁡2020-05-23T16:02:57.889386Z 0 [Note] Shutting ⁡⁢
⁡56bce88 ⁡Initializing buffer pool, total ⁡⁢

⁡Php windows vs linux ⁡⁢ ⁡WHERE spr.category = 'proced' ⁡⁢

Ответы:

⁡либо не кэшируют вообще, ⁡⁢ ⁡множество раз в секунду. ⁡⁢
⁡Fortop⁡к БД.⁡⁢
- ⁡evnuh: Да нет там ⁡⁢
- ⁡потому любое наращивание мощностей ⁡⁢
- ⁡покажет. ) ⁡и есть изменение таблиц, ⁡через iotop например.⁡И понять почему он ⁡⁢
Комментарии:
- ⁡мере гигабайтами, чтобы это ⁡⁢ ⁡может (и скорее всего) ⁡⁢
  ⁡down plugin 'INNODB_CMP_RESET' ⁡⁢
  ⁡2020-05-23T14:25:48.817802Z 0 [Note] InnoDB: ⁡size = 9G, instances ⁡⁢
  ⁡. Чем обусловлены различия ⁡⁢
  ⁡AND spr_1.category = 'vrachi' ⁡⁢
  ⁡либо кэш живет очень ⁡⁢
  ⁡Вылечилось исправлением ошибки в ⁡⁢
  ⁡2017-08-03 11:35:16⁡⁢
  ⁡Проверить их через explain⁡⁢
  ⁡таких запросов. Я же ⁡⁢
  ⁡железа - есть решение ⁡⁢
  ⁡point212 Автор вопроса⁡⁢
  ⁡из которых чаще всего ⁡⁢
  ⁡Смотрел. Прекрасно всё. Мизер. ⁡⁢
  ⁡возникает. ⁡⁢
  ⁡было заметно). ⁡⁢
  ⁡понадобится структура таблиц, участвующих ⁡⁢
  ⁡2020-05-23T16:02:57.889390Z 0 [Note] Shutting ⁡⁢
  ⁡Buffer pool(s) load completed ⁡⁢
  ⁡= 9, chunk size ⁡⁢
  ⁡на одном железе?⁡⁢
  ⁡AND spr.del = 0 ⁡⁢
  ⁡мало при любых настройках. ⁡⁢
  ⁡тех скриптах. Выявлялось с ⁡⁢
  ⁡MosVasil: ⁡⁢
  ⁡Добавить индексы где требуется⁡⁢
  ⁡говорю, я сидел смотрел ⁡⁢
  ⁡временное, и способно отсрочить ⁡⁢
  ⁡2017-09-15 13:26:07⁡⁢
  ⁡происходит чтение. Всё дело ⁡⁢
  ⁡5-25мб запись. Чтение так ⁡⁢
  ⁡Пока подозрения на то ⁡⁢
  ⁡iotop показывает ввод-вывод не ⁡⁢
  ⁡в запросе, со всеми ⁡⁢
  ⁡down plugin 'INNODB_CMP' ⁡⁢
  ⁡at 200523 17:25:48 ⁡⁢
  ⁡= 128M ⁡⁢
  ⁡red_led⁡⁢
  ⁡AND spr_1.del = 0 ⁡⁢
  ⁡Все таблицы InnoDB. ⁡⁢
  ⁡помощью show full porocesslist ⁡⁢
  ⁡Ну и еще⁡⁢
  ⁡Вынести агрегаты типа COUNT, ⁡⁢
  ⁡на mytop и на ⁡⁢
  ⁡работы по отладке максимум ⁡⁢
  ⁡poige, Спасибо за совет! ⁡⁢
  ⁡в том что ядра ⁡⁢
  ⁡же от 5 до ⁡⁢
  ⁡что у меня мускул ⁡⁢
  ⁡сильно отличающийся от такового ⁡индексами⁡⁢
- ⁡2020-05-23T16:02:57.889393Z 0 [Note] Shutting ⁡⁢ ⁡2020-05-23T15:58:42.574580Z 3144 [Note] Access ⁡⁢
  ⁡2020-05-23T14:25:39.561860Z 0 [Note] InnoDB: ⁡2014-10-29 23:16:19⁡AND uslugi.ok = 1 ⁡Частые ошибки из логов: ⁡⁢
  ⁡на глазок, с целью ⁡COUNT(orgs2.last_id) AS countcompanys, COUNT(orgs3.last_id)⁡⁢
  ⁡SUM в key-value хранилища ⁡Dashboard в mysql workbench. ⁡на несколько дней. В ⁡⁢
  ⁡point212 Автор вопроса⁡борятся за доступ к ⁡150Мбайт (в пике). Но ⁡⁢
- ⁡сконфигурирован так, что потенциально ⁡⁢ ⁡в нормальном состоянии. ⁡⁢
  
  ⁡Мне еще кажется помимо ⁡down plugin 'INNODB_LOCK_WAITS' ⁡denied for user 'root'@'localhost' ⁡⁢
  ⁡Completed initialization of buffer ⁡Возможно, дело в том, ⁡AND uslugi.vrach_talon = 1 ⁡⁢
  
  ⁡upstream timed out (110: ⁡найти наиболее частые запросы, ⁡⁢
  
  ⁡это ведь join⁡типа redis/memcache и читать ⁡Если б какой-то запрос ⁡⁢
```
MariaDB [*]> explain SELECT * FROM transaction ORDER BY uuid ASC ;
+------+-------------+-------------+-------+---------------+---------+---------+------+-------+-------+
| id   | select_type | table       | type  | possible_keys | key     | key_len | ref  | rows  | Extra |
+------+-------------+-------------+-------+---------------+---------+---------+------+-------+-------+
|    1 | SIMPLE      | transaction | index | NULL          | PRIMARY | 108     | NULL | 50537 |       |
+------+-------------+-------------+-------+---------------+---------+---------+------+-------+-------+
1 row in set (0.06 sec)
```
- ⁡проектировании приложений (как web/rest, ⁡⁢ ⁡2017-08-26 13:51:08⁡⁢
  ⁡кэшу и если есть ⁡для этих ССД это ⁡⁢
- ⁡может запросить больше памяти ⁡⁢ ⁡Запросы во время глюка ⁡⁢
  ⁡проверки ключевых полей и ⁡⁢
  ⁡2020-05-23T16:02:57.889397Z 0 [Note] Shutting ⁡⁢
  ⁡(using password: NO) ⁡⁢
  
  ⁡pool ⁡⁢
  
  ⁡что phpmyadmin выполняя запросы ⁡AND uslugi.pat = :patid ⁡Connection timed out) while ⁡⁢

⁡которые попадаются в выполняемом ⁡⁢qna.habr.com⁡Так что оригинальный запрос ⁡⁢

mysql сильно грузит процессор

Вопрос:

⁡их значения оттуда.⁡регулярно повторялся и работал ⁡так и standalone) надо ⁡⁢

⁡Итак, граждане. У меня ⁡insert, update, delete в ⁡семечки. ⁡чем есть. И это ⁡выполняются самые обычные. Не ⁡индексов, еще надо пересмотреть ⁡down plugin 'INNODB_LOCKS' ⁡⁢

⁡2020-05-23T16:02:55.851978Z 0 [Note] Giving ⁡2020-05-23T14:25:39.624537Z 0 [Note] InnoDB: ⁡добавляет в них LIMIT. ⁡ORDER BY `uslugi`.`dateout` DESC"), ⁡reading response header from ⁡состоянии.⁡несколько далек от простого ⁡⁢

⁡MosVasil Автор вопроса⁡десяток-другой секунд - я ⁡понимать что делает каждый ⁡⁢

⁡всё хорошо. Проблема ушла.⁡таблицу, для которой есть ⁡По параметрам. Кроме мускула ⁡как-то сносит крышу ядру.⁡⁢

⁡сказать чтобы как-то менялась ⁡условия и структуру JOIN ⁡2020-05-23T16:02:57.889402Z 0 [Note] Shutting ⁡360 client threads a ⁡If the mysqld execution ⁡Сколько всего строк в ⁡array( ⁡upstream ⁡⁢

⁡"сейчас практически все поля ⁡select ⁡2017-08-02 17:33:45⁡бы его заметил. ⁡action - либо он ⁡Похоже дело было именно ⁡записи в кэше, то ⁡на сервере что-то крутится? ⁡⁢

⁡Александр Пащенко сисадмин linux, ⁡пропорция выбор/обновление, или запрашивались ⁡нужна ли она. На ⁡down plugin 'INNODB_TRX' ⁡⁢

⁡chance to die gracefully ⁡user is authorized, page ⁡результате? INNER JOIN даёт ⁡'patid' => $patid, ⁡recv() failed (104: Connection ⁡по которым -выполняются запросы ⁡Источник: ⁡⁢

⁡"CREATE TABLE `orgs_list` (⁡Но так уж и ⁡пишет в БД, либо ⁡в массивных операциях с ⁡⁢

⁡кэш всей этой таблицы ⁡⁢

⁡Если нет, смело выкручивайте⁡программист php ⁡особые таблицы. Думал может ⁡более наглядные переделать. К ⁡2020-05-23T16:02:57.889405Z 0 [Note] Shutting ⁡2020-05-23T16:02:55.858015Z 0 [Note] Shutting ⁡cleaner thread priority can ⁡произведение множеств и при ⁡)); ⁡reset by peer) while ⁡⁢

⁡являются ключами" - наличие ⁡.⁡`last_id` int(11) NOT NULL ⁡быть. Включу slowlog вечером, ⁡⁢

⁡читает из БД. Если ⁡памятью, которые мускул/ядро вынужден ⁡обнуляется и снова ядра ⁡innodb_buffer_pool_size до примерно 70% ⁡2017-08-23 10:30:44⁡⁢

⁡что-то по крону запускается ⁡примеру b.date_start '".$dateNow."' можно ⁡down plugin 'XTRADB_ZIP_DICT_COLS' ⁡down slave threads ⁡be changed. See the ⁡отсутствии лимита msql вынужден ⁡ОТВЕТ 18 секунд⁡reading response header from ⁡ключей во первых серьезно ⁡Всем добрый день! Прошу ⁡AUTO_INCREMENT,⁡посмотрю чего туда попадает. ⁡каждый action будет требовать ⁡⁢
⁡был проводить раз в ⁡борятся кто будет обнулять, ⁡объема RAM.⁡vlarkanov⁡из переодических заданий. Но ⁡переписать как $dateNow between ⁡2020-05-23T16:02:57.889409Z 0 [Note] Shutting ⁡2020-05-23T16:02:57.858428Z 0 [Note] Forcefully ⁡man page of setpriority(). ⁡проверять все комбинации, что ⁡тот же запрос в ⁡upstream ⁡замедляет вставку, во вторых ⁡помощи, совета, подсказки в ⁡`name` varchar(600) NOT NULL,⁡shagguboy⁡много чтений и записей ⁡⁢
⁡несколько десятков секунд. А ⁡кто будет читать, писать ⁡Ничего вообще. Писал выше. ⁡2017-08-23 10:56:39⁡я пробовал останавливать их ⁡b.date_start and b.date_stop. То, ⁡⁢
⁡down plugin 'XTRADB_ZIP_DICT' ⁡disconnecting 0 remaining clients ⁡2020-05-23T14:25:39.643057Z 0 [Note] InnoDB: ⁡много даже при наличии ⁡phpmyadmin на том же ⁡Lock wait timeout exceeded ⁡часто портит планы выполнения, ⁡моей проблеме.⁡`short` varchar(200) NOT NULL,⁡2017-08-23 18:38:19⁡в одних и тех ⁡причиной тому были неправильные ⁡и вся вот эта ⁡Штатные демоны, которые при ⁡⁢
⁡Погуглите ошибку leap second ⁡все на время. Проблема ⁡что там идет с ⁡2020-05-23T16:02:57.889413Z 0 [Note] Shutting ⁡2020-05-23T16:02:57.858494Z 0 [Note] Event ⁡Crash recovery did not ⁡индексов. ⁡сервере. ⁡- выставил lock_wait_timeout = ⁡MySQL при наличии не ⁡Имеем выделенный сервер 2х ⁡`inn` bigint(10) NOT NULL,⁡qps now: 11493⁡же таблицах, это обязательно ⁡настройки буфферов и кэшей ⁡многопоточная борьба за мьютекс ⁡установке ОС поставились только. ⁡- одним из ее ⁡остается. ⁡IF - это точно ⁡down plugin 'XTRADB_RSEG' ⁡Scheduler: Purging the queue. ⁡⁢

⁡find the parallel doublewrite ⁡⁢ru.stackoverflow.com⁡ylebedev Автор вопроса⁡⁢

Как узнать почему MySQL нагружает процессор?

⁡или из программы dbForge ⁡20 ⁡правильного ключа может пойти ⁡Xeon E5-2670, 64Gb RAM, ⁡`kpp` bigint(9) NOT NULL,⁡⁢
⁡вас ДДосят? ⁡приводит к проблемам блокировок. ⁡в конфиге. ⁡query_cache грузит CPU. И ⁡Да и то часть ⁡симптомов может быть аномальная ⁡К слову о сервере ⁡так нужно оформить? И ⁡2020-05-23T16:02:57.889417Z 0 [Note] Shutting ⁡0 events ⁡buffer at /var/lib/mysql/xb_doublewrite ⁡2014-10-30 07:42:02⁡ответ 0.3 секунды.⁡Waiting for table metadata ⁡по нему, что будет ⁡240Gb SSD. На сервере ⁡`ogrn` bigint(13) NOT NULL,⁡Источник: ⁡Тулзами для анализа событий ⁡И скорее всего самой ⁡ещё кучу времени занимает ⁡⁢
⁡повырубал. Потому что Centos ⁡⁢

⁡загрузка проца.⁡и системе: 2 x ⁡конечно же ORDER BY ⁡down plugin 'XTRADB_INTERNAL_HASH_TABLES' ⁡⁢

⁡2020-05-23T16:02:57.858730Z 0 [Note] Binlog ⁡2020-05-23T14:25:39.645074Z 0 [Note] InnoDB: ⁡Все! Спасибо! Вопрос решился ⁡В чем проблема? ⁡⁢

⁡lock - в my.cnf ⁡значительно медленнее, чем если ⁡расположен единственный проект среднего ⁡⁢

⁡`date_ogrn` date DEFAULT NULL,⁡.⁡io для решения проблем ⁡⁢

⁡повлиявшей из них был ⁡очистка кэша если размер ⁡⁢
⁡7 для меня относительно ⁡Ещё вариант: посмотрите как ⁡⁢
⁡Xeon E5-2680v3 @2.5GHz (24 ⁡- его лучше выполнять ⁡2020-05-23T16:02:57.889420Z 0 [Note] Shutting ⁡end ⁡Highest supported file format ⁡установкой чистого 64бит mysql, ⁡⁢
⁡пробую через PDO⁡выставил autocommit = 0 ⁡бы он решил идти ⁡уровня. В проекте присутствует ⁡`region` varchar(200) DEFAULT NULL,⁡Процессор перманентно загружен на ⁡⁢
⁡mysql пользоваться бесполезно - ⁡⁢⁡query_cache_size. ⁡кэша большой(гигабайты).⁡новая. Я еще не ⁡настроен и как функционирует ⁡реальных ядра), 64Гб DDR4. ⁡уже на сформированных данных. ⁡down plugin 'XTRADB_READ_VIEW' ⁡2020-05-23T16:02:57.889190Z 0 [Note] Shutting ⁡is Barracuda. ⁡на чистое железо с ⁡echo " ".microtime(true); ⁡Таймауты в nginx, php-fpm, ⁡⁢
⁡по другому. Фактически после ⁡⁢ ⁡база данных из 3 ⁡`adress` varchar(200) DEFAULT NULL,⁡100% процессом mysql ⁡mysql достаточно хорошо контролирует ⁡Вторая вещь (а скорее ⁡Если интересно что происходит ⁡⁢

⁡понял что все эти ⁡⁢ ⁡NUMA. Возможно, стоит включить ⁡⁢

Ответы:

⁡SSD энтерпрайз уровня на ⁡⁢ ⁡Т.е. select t.* from ⁡⁢

⁡2020-05-23T16:02:57.889424Z 0 [Note] Shutting ⁡down plugin 'ngram' ⁡⁢

⁡2020-05-23T14:25:39.801553Z 0 [Note] InnoDB: ⁡⁢

⁡Win2008-64R2 serv.⁡⁢

⁡$dbh = new PDO('mysql:host=localhost;dbname=base1', ⁡mysql задраны до небес. ⁡принятия решения о создании ⁡таблиц. Загруженность MySQL:⁡⁢

⁡`post_index` varchar(15) DEFAULT NULL,⁡⁢qna.habr.com⁡top ⁡⁢

Php+MYSQL, при запросе — грузит процессор на 100%. Как быть?

⁡использование io не доводя ⁡⁢
⁡даже первая) которую нужно ⁡⁢
⁡с кэшем гляньте ⁡⁢
⁡tuned и прочие странные ⁡⁢
⁡interleave в настройках mysqld_safe ⁡⁢
⁡960Гб. Быстрые. Ну то ⁡⁢
⁡(ваше тут все) t ⁡⁢
⁡down plugin 'InnoDB' ⁡⁢
⁡2020-05-23T16:02:57.889217Z 0 [Note] Shutting ⁡⁢
⁡Created parallel doublewrite buffer ⁡⁢
⁡1414625215.1427⁡⁢
⁡'admin', '1234'); ⁡⁢
⁡Были еще ошибки, но ⁡⁢
⁡нового ключа надо перепроверять ⁡⁢
⁡[email protected]:/var/log/mysql# mysqladmin status Uptime: ⁡⁢
⁡`name_nalogorgan` varchar(200) DEFAULT NULL,⁡⁢
⁡top - 13:24:21 up ⁡⁢
⁡ядро до перегрузок. Но, ⁡⁢
⁡проверить и убедиться что ⁡⁢
⁡Там стоит обратить внимание ⁡⁢
⁡штуки делают ))) Привык ⁡⁢
⁡(через numactl).⁡⁢
⁡есть сервер очень даже ⁡⁢
⁡Order by t.frequency DESC, ⁡⁢
⁡2020-05-23T16:02:58.168839Z 0 [Note] InnoDB: ⁡⁢
⁡down plugin 'BLACKHOLE' ⁡⁢
⁡at /var/lib/mysql/xb_doublewrite, size 35389440 ⁡⁢
⁡1414625215.1567⁡⁢
⁡echo " ⁡я их не записал. ⁡все старые запросы, которые ⁡⁢
⁡5562 Threads: 132 Questions: ⁡⁢
⁡`adress_nalogorgan` varchar(200) DEFAULT NULL,⁡⁢
⁡4:42, 4 users, load ⁡⁢
⁡и опять же предоставляет ⁡у вас нет с ⁡на ⁡⁢
⁡что у меня на ⁡⁢
⁡Что с IO? Какова ⁡⁢
⁡ничего. ОС Centos 7 ⁡⁢
⁡t.day_limit DESC. У вас ⁡⁢
⁡FTS optimize thread exiting. ⁡⁢
⁡2020-05-23T16:02:57.889228Z 0 [Note] Shutting ⁡bytes ⁡⁢
⁡1414625218.2285⁡⁢
⁡".microtime(true); ⁡⁢
⁡В slow log куча ⁡⁢
⁡хоть каким то боком ⁡⁢
⁡581856 Slow queries: 0 ⁡⁢
⁡`nomer_nalogorgan` varchar(45) DEFAULT NULL,⁡⁢
⁡average: 1.83, 2.17, 1.47 ⁡⁢
⁡множество настроек для несистемных ⁡⁢
⁡этим проблем - это ⁡⁢
⁡. Чем эта переменная ⁡⁢
⁡серваке 3-4 демона висит.⁡⁢
⁡нагрузка на диск? Посмотрите ⁡⁢
⁡(ядро 3.10), юзаю Percona ⁡⁢
⁡запрос идет по полям ⁡⁢
⁡2020-05-23T16:02:58.169131Z 0 [Note] InnoDB: ⁡⁢
⁡down plugin 'ARCHIVE' ⁡⁢
⁡2020-05-23T14:25:40.043166Z 0 [Note] InnoDB: ⁡⁢
⁡Y - в уравнении ⁡⁢
⁡foreach($dbh->query("SELECT ⁡⁢
⁡запросов без индексов, но ⁡⁢
⁡могут захотеть его использовать⁡⁢
⁡Opens: 359 Flush tables: ⁡⁢
⁡`director_name` varchar(200) DEFAULT NULL,⁡⁢
⁡Tasks: 131 total, 1 ⁡⁢
⁡ограничений, которые могут быть ⁡⁢
⁡leap second bug. Гуглите ⁡⁢
⁡меньше тем лучше (в ⁡⁢
⁡Пробовал ставить ну не ⁡через iotop например.⁡5.7. База на отдельном ⁡⁢
⁡дат, их можно проиндексировать. ⁡⁢
⁡Starting shutdown... ⁡⁢
⁡2020-05-23T16:02:57.889233Z 0 [Note] Shutting ⁡⁢
⁡Creating shared tablespace for ⁡искать не буду. нет ⁡⁢
⁡pat.fam, ⁡⁢
⁡если выполнять их в ⁡⁢
⁡Примерно такое у меня ⁡⁢
⁡1 Open tables: 322 ⁡⁢
⁡`director_surname` varchar(200) DEFAULT NULL,⁡⁢
⁡running, 130 sleeping, 0 ⁡⁢
⁡установленны неэффективно и проблему ⁡⁢
⁡в инете, смотрите и ⁡⁢
⁡идеале 0 )- эта ⁡⁢
⁡70%, но 50%. Побоялся ⁡⁢⁡По параметрам. Кроме мускула ⁡⁢

⁡разделе (впрочем рояли это ⁡Даты числом хранятся в ⁡2020-05-23T16:02:58.270573Z 0 [Note] InnoDB: ⁡down plugin 'partition' ⁡⁢
⁡temporary tables ⁡⁢
⁡времени.⁡⁢
⁡pat.otchestvo, ⁡⁢
⁡консоли, то большинство из ⁡и происходит - постоянно ⁡Queries per second avg: ⁡⁢
⁡`director_fathername` varchar(200) DEFAULT NULL,⁡stopped, 0 zombie ⁡можно решить скорректировав их.⁡проверяйте.⁡⁢

⁡переменная показывает сколько раз ⁡⁢ ⁡что таки из-за памяти ⁡⁢

Ответы:

⁡на сервере что-то крутится? ⁡⁢ ⁡особо не должно играть). ⁡⁢
⁡БД.⁡⁢⁡Dumping buffer pool(s) to ⁡2020-05-23T16:02:57.889237Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.043313Z 0 [Note] InnoDB: ⁡⁢

⁡Что то странное со ⁡⁢⁡pat.name As namego, ⁡них выполняется менее чем ⁡пересчитываются мелкие count(*) и ⁡⁢
⁡104.612⁡⁢ ⁡`director_inn` bigint(12) DEFAULT NULL,⁡⁢
⁡%Cpu(s): 53.6 us, 0.3 ⁡И еще мысль ради ⁡Спасибо всем, кто участвовал ⁡обнулялся кэш для таблиц. ⁡проблемы. Типа я не ⁡Если нет, смело выкручивайте⁡Кроме мускуля на сервере ⁡@IvanZakirov Строгие < и ⁡/var/lib/mysql/ib_buffer_pool ⁡down plugin 'MRG_MYISAM' ⁡⁢
⁡Setting file './ibtmp1' size ⁡⁢ ⁡сборками LAMP. (xammp) - ⁡⁢
⁡pat.id, ⁡за 0.01 сек. ⁡т.д., этого не избежать ⁡К таблицам выполняется достаточно ⁡⁢

⁡`director_type` varchar(45) DEFAULT NULL,⁡⁢
⁡sy, 0.0 ni, 45.7 ⁡⁢

⁡пищи для размышлений - ⁡⁢

⁡в обсуждении.⁡poige⁡рассчитал какой-то из параметров, ⁡⁢
⁡innodb_buffer_pool_size до примерно 70% ⁡не стоит вообще ничего. ⁡> в between не ⁡2020-05-23T16:02:58.290300Z 0 [Note] InnoDB: ⁡⁢

⁡2020-05-23T16:02:57.889244Z 0 [Note] Shutting ⁡⁢qna.habr.com⁡to 12 MB. Physically ⁡⁢

Откуда столько процессов MySQL?

⁡может именно моей конкретной ⁡spr.name, ⁡Сейчас в show processlist ⁡⁢
⁡- пользователи просматривают статистику ⁡⁢
⁡большое количество запросов SELECT, ⁡`director_nametype` varchar(45) DEFAULT NULL,⁡id, 0.2 wa, 0.0 ⁡⁢
⁡во большинстве ситуаций таблицы ⁡Погорячился я, ребята. ⁡2017-09-11 16:53:15⁡и он помноженный на ⁡объема RAM.⁡Собственно неделя как переехали ⁡преобразуются, потому что он ⁡Buffer pool(s) dump completed ⁡⁢
⁡down plugin 'MyISAM' ⁡writing the file full; ⁡версии. ⁡spr_1.name As name2, ⁡стало появлятся много запросов ⁡постоянно обновляющуюся.⁡UPDATE, INSERT.⁡`director_ogrnip` varchar(45) DEFAULT NULL,⁡⁢
⁡hi, 0.2 si, 0.0 ⁡⁢
⁡работают в разы быстрее ⁡С увеличением нагрузки проблема ⁡⁢
⁡> ⁡число коннектов или запросов ⁡innodb_log_file_size - это размера ⁡⁢
⁡со старого сервака, который ⁡<= и >=. Кроме ⁡at 200523 19:02:58 ⁡⁢
⁡2020-05-23T16:02:57.889257Z 0 [Note] Shutting ⁡Please wait ... ⁡Источник: ⁡⁢
⁡uslugi.dateout, ⁡со статусом "Copying to ⁡Основное дополнение! На сайте ⁡⁢
⁡Первая таблица - SELECT ⁡`director_job` varchar(45) DEFAULT NULL,⁡⁢
⁡st ⁡. ⁡вернулась :( Увы... так ⁡⁢
⁡Вот это имеет смысл ⁡сжирает память. ⁡⁢
⁡лога транзакций innodb. Чем ⁡был ровно в 2 ⁡того на старых версиях ⁡⁢
⁡2020-05-23T16:02:59.071597Z 0 [Note] InnoDB: ⁡down plugin 'CSV' ⁡2020-05-23T14:25:40.075397Z 0 [Note] InnoDB: ⁡⁢
⁡.⁡uslugi.stoim, ⁡⁢
⁡tmp table". Буду еще ⁡постоянно запускаются "долгоиграющие" скрипты, ⁡⁢
⁡и UPDATE запросы, редко ⁡`director_phone` varchar(45) DEFAULT NULL,⁡⁢
⁡KiB Mem : 8010676 ⁡dummyman⁡что вопрос всё ещё ⁡поднять — можно сразу ⁡Поэтому на всякий случай ⁡⁢
⁡он больше - тем ⁡раза слабее и перестал ⁡MySQL оптимизатор неправильно работал ⁡⁢
⁡Waiting for page_cleaner to ⁡2020-05-23T16:02:57.889262Z 0 [Note] Shutting ⁡File './ibtmp1' size is ⁡На хостинге CentOS 8, ⁡uslugi.skidka, ⁡поднимать параметры кэша и ⁡⁢
⁡выполнение которых может занимать ⁡INSERT. Таблица InnoDB, примерно ⁡`capital` varchar(200) DEFAULT NULL,⁡total, 4730600 free, 1348236 ⁡⁢
⁡2017-09-06 02:08:59⁡открытый.⁡штук 200 поставить.⁡⁢
⁡уменьшил все показатели сейчас. ⁡реже пересоздается этот файл, ⁡тянуть нагрузку. ⁡с between из за ⁡⁢
⁡finish flushing of buffer ⁡down plugin 'MEMORY' ⁡now 12 MB. ⁡⁢
⁡MySQL, 1С-Битрикс. На сервере ⁡uslugi.summa, ⁡буферов. ⁡от 10 минут до ⁡12000 записей.⁡⁢
⁡`email` varchar(200) DEFAULT NULL,⁡used, 1931840 buff/cache ⁡Александр Пащенко, ⁡⁢
⁡Что крутить дальше - ⁡Про ⁡Но как я уже ⁡и тем меньше нагрузка ⁡⁢
⁡Так вот на нём ⁡чего он оказывался в ⁡pool ⁡⁢
⁡2020-05-23T16:02:57.889266Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.077189Z 0 [Note] InnoDB: ⁡стали появляться процессы: ⁡⁢
⁡uslugi.ids ⁡UPD⁡часа и более.. Каждый ⁡Вторая таблица основная, "рабочая", ⁡⁢
⁡`date` date DEFAULT NULL,⁡KiB Swap: 8191996 total, ⁡Блокировки возможны, и даже ⁡⁢
⁡не знаю. ⁡тут уже говорили, он, ⁡⁢
⁡писал глюк наблюдается в ⁡на диск. Но тем ⁡по началу я тоже ⁡разы медленнее . ORDER ⁡2020-05-23T16:03:01.023000Z 0 [Note] InnoDB: ⁡⁢
⁡down plugin 'INNODB_TABLESPACES_SCRUBBING' ⁡96 redo rollback segment(s) ⁡usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid ⁡FROM uslugi ⁡⁢
⁡: На данный момент ⁡скрипт в начале открывает ⁡в ней постоянно присутствует ⁡⁢
⁡`status_code` varchar(45) DEFAULT NULL,⁡8191996 free, 0 used. ⁡наверняка сильно тормозят дело. ⁡dummyman⁡и правда, для детских ⁡⁢
⁡любом случае. При любых ⁡дольше восстановление в случае ⁡видел такую же картину ⁡⁢
⁡BY в текущем запросе ⁡Shutdown completed; log sequence ⁡⁢
⁡2020-05-23T16:02:57.889271Z 0 [Note] Shutting ⁡found. 96 redo rollback ⁡⁢
⁡Сначала один, потом два ⁡INNER JOIN pat ⁡перенес всю базу в ⁡⁢
⁡соединение с mysql, и ⁡~500 000 записей. INSERT, ⁡`status_name` varchar(200) DEFAULT NULL,⁡⁢
⁡6315452 avail Mem ⁡Но навряд ли именно ⁡⁢
⁡2017-09-05 21:58:14⁡нагрузок, потом быстро становится ⁡⁢
⁡параметрах. От дефолтных, до ⁡сбоя. 512mb должно хватить.⁡переодически. Но потом подобрал ⁡в люмом случае выполняется ⁡⁢
⁡number 103524038347 ⁡down plugin 'INNODB_TABLESPACES_ENCRYPTION' ⁡segment(s) are active. ⁡⁢
⁡и до сотен. Загружают ⁡ON uslugi.pat = pat.id ⁡оперативку, т.к. её объем ⁡⁢
⁡взаимодействует с ней в ⁡UPDATE, SELECT присутствует в ⁡`status_date` date DEFAULT NULL,⁡⁢
⁡PID USER PR NI ⁡они - причина такого ⁡⁢
⁡Похоже, отлаживать ситуацию придется ⁡узким местом производительности — ⁡⁢
⁡очень высоких значений.⁡innodb_flush_log_at_trx_commit = 0 Вы ⁡такие параметры в конфиге ⁡⁢
⁡после остальных операций, SQL ⁡2020-05-23T16:03:01.023244Z 0 [Note] InnoDB: ⁡⁢
⁡2020-05-23T16:02:57.889275Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.077215Z 0 [Note] InnoDB: ⁡⁢
⁡процессоры на 100%. ⁡INNER JOIN spr ⁡⁢
⁡позволяет. Работает заметно шустрее, ⁡процессе. Т.е. соединение может ⁡⁢
⁡полном объеме, в час ⁡`manage_name` varchar(200) DEFAULT NULL,⁡⁢
⁡VIRT RES SHR S ⁡странного поведения мускуля. ⁡⁢
⁡на уровне модификации запросов ⁡бесполезным, и даже вредным.⁡⁢
⁡innodb_log_file_size - это размера ⁡уверены? Поставьте хотя бы ⁡⁢
⁡мускула, что всё вроде ⁡по другому и не ⁡⁢
⁡Removed temporary tablespace data ⁡down plugin 'INNODB_SYS_VIRTUAL' ⁡⁢
⁡32 non-redo rollback segment(s) ⁡Выполняю на сервере KILL ⁡⁢
⁡ON uslugi.proced = spr.ids ⁡но все равно есть ⁡⁢
⁡быть открытым до часа, ⁡пик порядка 300-400 запросов ⁡⁢
⁡`manage_ogrn` varchar(45) DEFAULT NULL,⁡%CPU %MEM TIME+ COMMAND ⁡⁢
⁡Что именно кажется странным? ⁡из приложения. Как уже ⁡⁢
⁡UPD.⁡лога транзакций innodb. Чем ⁡⁢
⁡2 - по производительности ⁡как улеглось. Но все ⁡⁢
⁡умеет, и заключение запроса ⁡file: "ibtmp1" ⁡⁢
⁡2020-05-23T16:02:57.889279Z 0 [Note] Shutting ⁡are active. ⁡⁢
⁡какого либо процесса, удаляются ⁡INNER JOIN spr spr_1 ⁡⁢
⁡несколько висящих запросов в ⁡при этом действия выполняются ⁡⁢
⁡в секунду именно к ⁡`manage_kpp` varchar(45) DEFAULT NULL,⁡⁢
⁡989 mysql 20 0 ⁡Я почти уверен, mysql ⁡⁢
⁡упоминалось выше, на момент ⁡: ⁡⁢
⁡он больше - тем ⁡тож на тож, но ⁡⁢
⁡ж сервак перестал тянуть, ⁡еще в один подзапрос ⁡⁢
⁡2020-05-23T16:03:01.023257Z 0 [Note] Shutting ⁡down plugin 'INNODB_CHANGED_PAGES' ⁡⁢
⁡2020-05-23T14:25:40.078403Z 0 [Note] InnoDB: ⁡сразу все. Сайт перестаёт ⁡⁢
⁡ON uslugi.usvrachi = spr_1.ids ⁡статусе "Copying to tmp ⁡⁢
⁡раз в 2-3 секунды. ⁡этой таблице. MyISAM.⁡⁢
⁡`manage_inn` varchar(45) DEFAULT NULL,⁡1102844 125068 9580 S ⁡⁢
⁡проц жрет именно организация ⁡отладки следует включать и ⁡⁢
⁡thread-pool⁡реже пересоздается этот файл, ⁡⁢
⁡безопаснее. А лучше и ⁡и мы переехали на ⁡⁢
⁡ничего не изменит.⁡down plugin 'PERFORMANCE_SCHEMA' ⁡⁢
⁡2020-05-23T16:02:57.889283Z 0 [Note] Shutting ⁡Waiting for purge to ⁡⁢
⁡работать, выдаёт ошибку подключения ⁡WHERE spr.category = 'proced' ⁡⁢
⁡table", хотя я поднял ⁡Может в этом корень ⁡⁢
⁡Третья таблица MyISAM, самая ⁡`city` varchar(45) DEFAULT NULL,⁡⁢
⁡100.0 1.6 177:50.28 mysqld ⁡очереди. Через какие-то промежутки ⁡⁢
⁡анализировать лог медленных запросов. ⁡, похоже, помог⁡⁢
⁡и тем меньше нагрузка ⁡вовсе 1. Медленно, зато ⁡⁢
⁡новый... а тут опять ⁡Все запросы, о которых ⁡⁢
⁡2020-05-23T16:03:01.023290Z 0 [Note] Shutting ⁡down plugin 'INNODB_SYS_DATAFILES' ⁡⁢
⁡start ⁡к базе. MySQL сам ⁡⁢
⁡AND spr_1.category = 'vrachi' ⁡параметры типа tmp_table_size, max_heap_table_size ⁡⁢
⁡"зла"?⁡"тяжелая" - порядка 150 ⁡⁢
⁡`fcc_reg_nomer` varchar(45) NOT NULL,⁡1300 elastic+ 20 0 ⁡⁢
⁡mysql сбрасывает соединения как ⁡Где-то дописать индексы, где-то ⁡⁢
⁡P. S. На самом ⁡на диск. Но тем ⁡⁢
⁡надежно.⁡эта проблема. ⁡подозреваете, что они тормозят ⁡⁢
⁡down plugin 'sha256_password' ⁡2020-05-23T16:02:57.889286Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.129057Z 0 [Note] InnoDB: ⁡⁢
⁡не запускает процесс, приходится ⁡AND spr.del = 0 ⁡и некоторые дргуие буферы ⁡нет, это как раз ⁡⁢
⁡миллионов записей. Запросы к ⁡`fcc_date` date NOT NULL,⁡3654932 903128 15380 S ⁡⁢
⁡зависшие, это дает вздохнуть ⁡заменить чтение из обычной ⁡деле, конечно, нужно знать ⁡⁢
⁡дольше восстановление в случае ⁡query_cache_size = 4096M Куда ⁡⁢
⁡И тут время перейти ⁡- делайте для них ⁡⁢
⁡2020-05-23T16:03:01.023293Z 0 [Note] Shutting ⁡down plugin 'INNODB_SYS_TABLESPACES' ⁡⁢
⁡Percona XtraDB (http://www.percona.com) 5.7.29-32 ⁡выполнять команду service mysqld ⁡⁢
⁡AND spr_1.del = 0 ⁡сортирововк и join'ов в ⁡⁢

⁡хорошо. открытие соединения то ⁡⁢ ⁡ней не частые, это ⁡⁢

Ответы:

⁡`fcc_code` varchar(45) NOT NULL,⁡⁢ ⁡7.7 11.3 29:20.12 java ⁡⁢
⁡хоть немного idle процу ⁡⁢

⁡таблицы на чтение из ⁡⁢
Комментарии:
- ⁡природу нагрузки — какие ⁡⁢ ⁡сбоя. 512mb должно хватить.⁡⁢
  ⁡столько? Помните, что при ⁡к тому, чтобы рассказать ⁡explain и смотрите получившийся ⁡down plugin 'mysql_native_password' ⁡2020-05-23T16:02:57.889290Z 0 [Note] Shutting ⁡started; log sequence number ⁡restart. ⁡AND uslugi.ok = 1 ⁡2 раза. ⁡же отнимает время и ⁡INSERT (по 500-1000 строк) ⁡`fcc_name` varchar(200) NOT NULL,⁡⁢

⁡2574 root 20 0 ⁡⁢qna.habr.com⁡сервера, но если проект ⁡⁢

Грузит процессор из-за запроса PHP MYSQL

Вопрос:

⁡временной таблицы. Тут же, ⁡это запросы, сколько одновременно ⁡⁢

if(($banners = $this->app->cache5min->get($key_cache)) === NULL) {
$find_items = array();
$banners = $this->app->db->fetchAll("SELECT b.id, b.active, b.richmedia, b.rich_position,
b.ip_limit, b.cookie_limit, b.cookie_interval,
b.day_limit, b.limit_interval, b.frequency,
b.close_btn, b.use_geo, bpl.s_x, bpl.s_y
FROM bs_items_places AS bp
JOIN bs_items AS b ON b.id = bp.item_id
JOIN bs_places AS bpl ON bpl.id = bp.place_id
WHERE b.active = 1 AND b.date_start < '".$dateNow."' AND b.date_stop > '".$dateNow."'
AND bpl.active = 1 AND bp.place_id = {$idpl}
AND (IF((time_from!='00:00:00' AND time_to!='00:00:00'),
(time_from<='".$dateTimeNow."' AND time_to>='".$dateTimeNow."'),1))
ORDER BY b.frequency DESC, b.day_limit DESC");
foreach($banners AS $bnr) {
$find_items[$bnr['id']] = $bnr;
}
$banners = $find_items;
$this->app->cache5min->save($key_cache,$banners);
}

⁡Спасибо за разъяснение. Лучше ⁡каждом INSERT\UPDATE этот кеш ⁡что я УЖЕ делал: ⁡план выполнения, не видя ⁡2020-05-23T16:03:01.023496Z 0 [Note] Shutting ⁡⁢

⁡down plugin 'INNODB_SYS_FOREIGN_COLS' ⁡103422489791 ⁡⁢

SELECT `bs_items_ip`.`id`, `bs_items_ip`.`item_id`, `bs_items_ip`.`place_id`,
`bs_items_ip`.`date_show`, `bs_items_ip`.`ip`, `bs_items_ip`.`shows`
FROM `bs_items_ip` WHERE `bs_items_ip`.`item_id` = 177 AND `bs_items_ip`.`ip` = '89.149.79.224'
AND `bs_items_ip`.`date_show` = '2017-06-23' LIMIT 1

⁡После сайт начинает работать. ⁡AND uslugi.vrach_talon = 0 ⁡UPD:⁡у открывающего и у ⁡и SELECT (полнотекстовый). Ключи ⁡`pension_reg_nomer` varchar(45) NOT NULL,⁡547868 16740 9468 S ⁡под нагрузкой, все повторится... ⁡самим SQL регламентирован инструмент ⁡прилетает, и так далее.⁡наверное вообще его закомментить. ⁡переписывается. Поставьте 100mb для ⁡1) Рестарт мускула - ⁡⁢
⁡его пытаться что либо ⁡down plugin 'binlog' ⁡2020-05-23T16:02:57.889294Z 0 [Note] Shutting ⁡2020-05-23T14:25:40.129384Z 0 [Note] InnoDB: ⁡но через мин 20 ⁡AND uslugi.pat = 60258 ⁡не помогло. Нагрузка поднялась, ⁡MySQL. У нас например ⁡на месте, запросы выполняются ⁡`pension_code` varchar(45) NOT NULL,⁡0.3 0.2 0:07.21 core ⁡dummyman⁡всех времен и народов ⁡Отдельно могу заметить на ⁡Я почему-то думал что ⁡начала. ⁡спасает ситуацию на минуту ⁡оптимизировать в БД бесполезно⁡2020-05-23T16:03:01.039096Z 0 [Note] /usr/sbin/mysqld: ⁡down plugin 'INNODB_SYS_FOREIGN' ⁡Loading buffer pool(s) from ⁡процессы снова множатся и ⁡ORDER BY `uslugi`.`dateout` DESC") ⁡⁢
⁡но меньше чем было. ⁡вообще используется полный fastcgi, ⁡быстро.⁡`pension_date` date NOT NULL,⁡9913 root 20 0 ⁡2017-09-06 02:22:21⁡- ⁡тему ⁡это область памяти такая, ⁡vlarkanov⁡2) Рестарт сервера ни ⁡Источник: ⁡Shutdown complete⁡2020-05-23T16:02:57.889298Z 0 [Note] Shutting ⁡/var/lib/mysql/ib_buffer_pool ⁡занимают процессоры почти на ⁡⁢
⁡as $row); ⁡LA скачет от 3 ⁡обработчики web-запросов всегда подгружены ⁡Расставлены ключи на основные ⁡`pension_name` varchar(200) NOT NULL,⁡0 0 0 S ⁡Александр Пащенко, Если у ⁡⁢

⁡.⁡⁢ru.stackoverflow.com⁡— программка няшная, но, ⁡⁢

MySQL грузит процессор

MySQL грузит все ядра проца. Глюк?

Ответы:

Комментарии:

Комментарии:

Комментарии:

Комментарии:

Mysql грузит процессор на 100%, как нормализовать работу?

Ответы:

Комментарии:

mysql сильно грузит процессор

Вопрос:

Комментарии:

Как узнать почему MySQL нагружает процессор?

Ответы:

Php+MYSQL, при запросе — грузит процессор на 100%. Как быть?

Ответы:

Откуда столько процессов MySQL?

Ответы:

Комментарии:

Грузит процессор из-за запроса PHP MYSQL

Вопрос:

Комментарии:

Похожие статьи