- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
sladkydze, если клиенту пофиг - режте ему иопсы, чтоб ему стало не пофиг.
кстати что за контент там у него?
200 мб/с запись - это что-то нереальное, что туда можно писать постоянно, да еще в базу?
а свопиться криво настроенное ПО и ось могут и при вроде бы свободной оперативке.
отключите swap, список подозреваемых уменьшится.
Так не бывает, за все надо платить
Или резать диск или пусть клиент нанимает админа
200 мб/с запись - это что-то нереальное, что туда можно писать постоянно, да еще в базу?
Например, временные файлы при сортировках и группировках.
Это например. А что на самом деле придется клиенту узнать.
может там optimize table делается при каждом хите к с CMS :)
смотрите processlist и лог медленных запросов (можно принудительно время медленных запросов уменьшить до пары секунд, чтобы больше запросов-кандидатов логировалось)
Отчитываюсь.
1. Машине пробно было добавлено 16 ГБ оперативки. Практически полностью прекратилось чтение с диска (все закэшировалось). Но писать оно продолжало с прежней интенсивностью.
2. После этого клиент сделал рамдиск на 1 ГБ и начал скидывать туда временные таблицы MySQL, и все порешалось :) Машина перестала ацки писать на диск. Так что вот она, причина.
Всем спасибо за участие.
P.S. Вот графическое отображение результатов оптимизации: ftp://tech.vds4you.ru/Images/Musor/HDD-optimization.jpg
В принципе, это еще раз доказывает, что говнокоду или кривой настройке любое железо нипочем. Всё положит на лопатки.
2. После этого клиент сделал рамдиск на 1 ГБ и начал скидывать туда временные таблицы MySQL, и все порешалось :) Машина перестала ацки писать на диск. Так что вот она, причина.
это костыль частично решивший проблему( что тоже хорошо ), а не причина.
причины уже назывались: отсутствие индексов, не настроенный mysql, или кривые запросы.
как я понял, оно и дальше свопится, только в рам :)
admak, оно не свопается.
MySQL пишет на диск, если не хватает tmp_table_size.
В основном это происходит когда не юзают индексы.
И всякие джойны тоже
admak, оно не свопается.
я в курсе.. но сути это не меняет. получается, что своп не системный, а mysql-ный :)
к сожалению не все так просто с tmp_table_size... даже если хватает tmp_table_size, но во временной табличке есть хоть одно текстовое поле (text, mediumtext и т.д.) то она все-равно будет писаться на диск. также есть ограничения на размер строки и чего-то еще.
в форках Percona и MarinaDB что-то пытаются испровать, но проблема эта еще не решена.