- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день!
Есть БД mysql, на текущий момент размером в 7 GB. Таблицы InnoDB.
На начальном, этапе при сборе данных в базу, скорость создания комплектов записей (несколько связанных записей в разных таблицах) составляла 100-130 в минуту.
Сейчас идет пересчет базы, через update. Сначала скорость обработки комплектов записей была примерно прежней 100-130 в минуту, но потом резко упала до 10-20 в минуту.
Причем скорость создания одного комплекта записей меняется от 0,1 сек до 15 сек.
Попытался разобраться с настройкой mysql (файл my.cnf). Мало что в этом понимаю. Cтояли совсем скромные параметры по умолчанию. Поставил
innodb_buffer_pool_size = 6G
Поменял еще пару настроек, остальное не трогал.
Теперь mysql стал использовать больше памяти (с 0,5 ГБ до 1,9 ГБ), но все равно не весь разрешенный объем.
Загрузку процессора не полная (intel core i7).
top - 13:42:57 up 3:58, 1 user, load average: 2.78, 3.02, 3.18
Tasks: 137 total, 2 running, 135 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.8 us, 5.1 sy, 0.0 ni, 80.2 id, 3.9 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 16156044 total, 9949348 used, 6206696 free, 864868 buffers
KiB Swap: 8387568 total, 0 used, 8387568 free, 5975988 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2886 mysql 20 0 7030m 1.9g 8160 S 104.1 12.1 236:22.69 mysqld
Получается, что раз БД не использует оперативную память, процессоры не загружены, то проблема в скорости записи на HDD? (стоят 2 обычных HDD в raid 1). Не знаю как это проверить.
Можно как-то ускорить процесс? Например, как то заставить mysql сливать изменения на HDD раз в минуту.
Может проблема в чем-то другом и поможет грамотная настройка my.cnf?
Приведу результаты анализа через mysqltuner:
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.31-0+wheezy1
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 4G (Tables: 244) //это другая БД, но с ней проблем нет, 99% операций на чтение
[--] Data in InnoDB tables: 6G (Tables: 27)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 744K (Tables: 12)
[!!] Total fragmented tables: 40
-------- Performance Metrics -------------------------------------------------
[--] Up for: 2h 57m 3s (1M q [171.188 qps], 35K conn, TX: 5B, RX: 316M)
[--] Reads / Writes: 84% / 16%
[--] Total buffers: 6.1G global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 6.5G (41% of installed RAM)
[OK] Slow queries: 0% (7/1M)
[OK] Highest usage of available connections: 11% (17/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/1.0G
[OK] Key buffer hit rate: 98.9% (73M cached / 808K reads)
[OK] Query cache efficiency: 54.1% (836K cached / 1M selects)
[!!] Query cache prunes per day: 4521356
[OK] Sorts requiring temporary tables: 2% (649 temp sorts / 31K sorts)
[OK] Temporary tables created on disk: 0% (79 on disk / 69K total)
[OK] Thread cache hit rate: 99% (141 created / 35K connections)
[OK] Table cache hit rate: 28% (400 open / 1K opened)
[OK] Open file limit used: 58% (604/1K)
[OK] Table locks acquired immediately: 99% (876K immediate / 876K locks)
[!!] InnoDB data size / buffer pool: 6.7G/6.0G
Ну как минимум, это innodb_buffer_pool_size должен быть больше или равен InnoDB data size, а так же
Key buffer size должен быть больше или равен всему размеру индексов, innodb_flush_log_at_trx_commit = 0
и innodb_flush_method = O_DIRECT. InnoDB медленнее, чем Myisam, но надёжнее в плане восстановления после сбоя.
Лучше уделите внимание нормальной настройке my.cnf, почитайте разные манюалы, советы людей и т.д.
Ну а вообще, надёжнее будет нанять специалиста для этого.
P.S. SSD диск так же, существенно, ускорит всё ваше добро...
Наблюдаю скорость 230 комплектов в минуту и она продолжает увеличиваться. Спасибо, очень помогли!
Скорость обработки дошла до 0,01-0,03 сек. против 1-15 сек ранее. Это ускорение в 100-500 раз. Если бы скрипт не содержал вычислений, а состоял только из записи в БД, то прирост был бы еще значительнее. Просто чудеса благодаря четырем параметрам в my.cnf
Имейте в виду, что кэш со временем "прогревается" и работает быстрее сам по себе.
Добрый день!
Можно как-то ускорить процесс? Например, как то заставить mysql сливать изменения на HDD раз в минуту.
Советую вам поиграться с sysctl-переменными, подробнее можно тут почитать, например: http://drupal-admin.ru/blog/%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-linux-%D0%BF%D0%BE%D0%B4-%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D1%83-%D0%BA%D1%8D%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B9-%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B8-%D0%BD%D0%B0-%D0%B4%D0%B8%D1%81%D0%BA
Вот из основного:
/proc/sys/vm/dirty_writeback_centisecs (default 500): в сотых долях секунд. Этот параметр означает как часто pdflush возобновляет работу для записи данных на диск. По умолчанию возобновляет работу 2 потока каждые 5 секунд.
Возможно недокументированное поведение, которое пресекает попытки уменьшения
dirty_writeback_centisecs для более агрессивного кэширования данных процессом pdflush. Например, в ранних версиях ядра 2.6 Linux в файле mm/page-writeback.c код включал логику, которая описывалась "если запись на диск длится дольше, чем параметр dirty_writeback_centisecs, тогда нужно поставить интервал в 1 секунду". Эта логика описана только в коде ядра, и ее функционирование зависит от версии ядра Linux. Так как это не очень хорошо, поэтому вы будете защищены от уменьшения этого параметра.
/proc/sys/vm/dirty_expire_centiseconds (default 3000): в сотых долях секунд. Этот параметр указывает как долго данные могут находится в кэше, после чего должны быть записаны на диск. Значение по умолчанию очень долгое: 30 секунд. Это означает, что при нормальной работе до тех пор пока в кэш не запишется достаточно данных для вызова другого метода pdflush, Linux не будет записывать данные на диск, находящиеся в кэше менее 30 секунд.
/proc/sys/vm/dirty_background_ratio (default 10): Максимальный процент оперативной памяти, который может быть заполнен страничным кэшем до записи данных на диск. Некоторые версии ядра Linux могут этот параметр устанавливать в 5%.
В большинстве документации этот параметр описывается как процент от общей оперативной памяти, но согласно исходным кодам ядра Linux это не так. Глядя на meminfo, параметр dirty_background_ratio расчитывается от величины MemFree + Cached - Mapped. Поэтому для нашей демонстрационной системы 10% составляет немного меньше, чем 250MB, но не 400MB.
Ну и да, SSD - неплохой выход из ситуации, тем более что у вас не такая уже и объёмная база.
Evas, всё верно написал, но
InnoDB - быстрее
Myisam - надежне
Evas, всё верно написал, но
InnoDB - быстрее
Myisam - надежне
Ничего не перепутали?
---------- Добавлено 12.05.2014 в 20:01 ----------
Кроме того innoDB таки может быть и быстрее, зависит от структуры скрипта, запросов.