Высокая нагрузка на диск со стороны MySQL

123
Mik Foxi
На сайте с 02.03.2011
Offline
1183
#11

sladkydze, если клиенту пофиг - режте ему иопсы, чтоб ему стало не пофиг.

кстати что за контент там у него?

200 мб/с запись - это что-то нереальное, что туда можно писать постоянно, да еще в базу?

а свопиться криво настроенное ПО и ось могут и при вроде бы свободной оперативке.

отключите swap, список подозреваемых уменьшится.

Антибот, антиспам, веб фаервол, защита от накрутки поведенческих: https://antibot.cloud/ (Зеркало: https://антибот.рф/ ) Форум на замену серчу: https://foxi.biz/
Andreyka
На сайте с 19.02.2005
Offline
822
#12

Так не бывает, за все надо платить

Или резать диск или пусть клиент нанимает админа

Не стоит плодить сущности без необходимости
N
На сайте с 06.05.2007
Offline
419
#13
foxi:
200 мб/с запись - это что-то нереальное, что туда можно писать постоянно, да еще в базу?

Например, временные файлы при сортировках и группировках.

Это например. А что на самом деле придется клиенту узнать.

Кнопка вызова админа ()
iHead
На сайте с 25.04.2008
Offline
137
#14

может там optimize table делается при каждом хите к с CMS :)

смотрите processlist и лог медленных запросов (можно принудительно время медленных запросов уменьшить до пары секунд, чтобы больше запросов-кандидатов логировалось)

Рекомендуемый хостинг партнер 1С-Битрикс (https://www.ihead.ru/bitrix/), PHP-хостинг (https://www.ihead.ru/php/), доверенный партнер RU-CENTER (https://www.ihead.ru/news/573.html), официальный представитель REG.RU в Кирове (https://www.ihead.ru/news/851.html)
sladkydze
На сайте с 07.12.2012
Offline
243
#15

Отчитываюсь.

1. Машине пробно было добавлено 16 ГБ оперативки. Практически полностью прекратилось чтение с диска (все закэшировалось). Но писать оно продолжало с прежней интенсивностью.

2. После этого клиент сделал рамдиск на 1 ГБ и начал скидывать туда временные таблицы MySQL, и все порешалось :) Машина перестала ацки писать на диск. Так что вот она, причина.

Всем спасибо за участие.

Предлагаю VDS, IaaS, Dedicated. http://riaas.ru (http://riaas.ru)
sladkydze
На сайте с 07.12.2012
Offline
243
#16

P.S. Вот графическое отображение результатов оптимизации: ftp://tech.vds4you.ru/Images/Musor/HDD-optimization.jpg

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

A
На сайте с 19.07.2010
Offline
130
#17
sladkydze:
2. После этого клиент сделал рамдиск на 1 ГБ и начал скидывать туда временные таблицы MySQL, и все порешалось :) Машина перестала ацки писать на диск. Так что вот она, причина.

это костыль частично решивший проблему( что тоже хорошо ), а не причина.

причины уже назывались: отсутствие индексов, не настроенный mysql, или кривые запросы.

как я понял, оно и дальше свопится, только в рам :)

.............
P
На сайте с 16.03.2009
Offline
144
#18

admak, оно не свопается.

MySQL пишет на диск, если не хватает tmp_table_size.

В основном это происходит когда не юзают индексы.

Andreyka
На сайте с 19.02.2005
Offline
822
#19

И всякие джойны тоже

A
На сайте с 19.07.2010
Offline
130
#20
poiuty:
admak, оно не свопается.

я в курсе.. но сути это не меняет. получается, что своп не системный, а mysql-ный :)

MySQL пишет на диск, если не хватает tmp_table_size.

к сожалению не все так просто с tmp_table_size... даже если хватает tmp_table_size, но во временной табличке есть хоть одно текстовое поле (text, mediumtext и т.д.) то она все-равно будет писаться на диск. также есть ограничения на размер строки и чего-то еще.

в форках Percona и MarinaDB что-то пытаются испровать, но проблема эта еще не решена.

123

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий