Сколько операций выбора в секунду может запускать сервер MySQL?


19

Я пишу бизнес-план, и мне нужно смоделировать стоимость, когда мой сайт будет охватывать 500 000 уникальных посетителей.

  • посетителей: 500.000
  • просмотров: 1 500 000
  • просмотров страниц паука: 500 000
  • всего просмотров страниц: 2 000 000

Каждая страница выполняет 50 запросов + -

  • запросов в день: 100 миллионов
  • в час: 4 миллиона
  • в минуту: 70000
  • в секунду: 1200
  • пик: 3000

При выполнении этого расчета мне нужно 3000 запросов в секунду ... какой сервер может обработать это?

Проблема в том, что на самом деле мой сайт делает 2000 посещений в день и имеет - + 150/200 запросов / секунду ... с этого момента я буду ожидать 50 000 запросов / секунду.

Сколько серверов мне нужно в кластере или репликации управлять этой работой?


5
Какой сайт 8k + запрашивает посещение?
Игнасио Васкес-Абрамс

5
Вам нужно сразу пересмотреть проект системы.
Chopper3

1
Недостаточно информации, потому что вы ничего не сказали нам о том, что действительно важно - самих запросах. Также не нужно рассказывать нам о машине, на которой вы работаете. Это 486? Последний и самый лучший суперкомпьютер или что-то среднее? Все те цифры, которые вы перечислили, не имеют отношения к вопросу. Пожалуйста, предоставьте СООТВЕТСТВУЮЩУЮ информацию.
Джон Гарденье

> Какой сайт 8k + запрашивает посещение? Я получаю 2000 уникальных посетителей, но каждый посетитель открывает много страниц, + у меня много пауков внутри. 2000 уникальных пользователей генерируют 6000 уникальных ips, открывая более 120 000 открытых страниц ежедневно. спасибо

Ответы:


22

Раньше я работал в компании, занимающейся электронной коммерцией, с веб-сайтом, который посещал несколько миллионов страниц в день. У нас был один DELL PE 1750 с 2 одноядерными процессорами и 2 ГБ оперативной памяти, размер базы данных ок. 4ГБ. В часы пиковой нагрузки этот сервер обрабатывает до 50 000 запросов в секунду.

Сказав это: база данных была хорошо структурирована, все запросы были точно настроены (у нас были еженедельные сеансы, анализирующие медленные журналы запросов и исправление запросов и индексов), а также была точно настроена настройка сервера. Кэширование, безусловно, хорошая идея, но в любом случае MySQL делает это, вам просто нужно проанализировать производительность, а затем точно настроить, как используется ваша память (кеш запросов и другие параметры).

Исходя из этого опыта, я могу сказать вам, что наибольшее влияние оказывают отсутствующие индексы, неправильные индексы и плохой дизайн базы данных (например, длинные строковые поля в качестве первичных ключей и подобная ерунда).


8

Все зависит от того, насколько сложен запрос, сколько памяти у серверов и насколько быстры диски.

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


Или какие-то серьезные изменения схемы и переиндексация ...
Массимо

3
Настройка ВСЕГДА предпочтительнее добавления дополнительного оборудования. Добавление большего количества оборудования просто маскирует проблему до тех пор, пока проблема не станет намного труднее решить.
Мрденный

Спасибо за ответ, так что я думаю, что 2 сервера параллельно + 1 пассивный для перенаправления должны быть в порядке, верно? я говорю о 2x четырехъядерных серверах с 32 г оперативной памяти и быстрыми дисками. я прав? помните, что мне нужны выступления!

1
все хорошо настроено и проиндексировано, у меня 1 или 2 медленных запроса в неделю (а время медленных запросов составляет всего 2 секунды), так или иначе, я пишу бизнес-план, и я хотел бы знать, какой тип пула серверов может управлять 12 000 000 открытых страниц ежедневно, генерируя 8000 запросов в секунду

8000 запросов в секунду не так уж много. Один 16-ядерный сервер, вероятно, сделает свое дело. 64 гигабайта оперативной памяти (или более или менее в зависимости от размера базы данных и объема данных, которые необходимо хранить в кеше в любое время) должны помочь. Моя БД (предоставленная SQL Server) занимает 1 ТБ на 16-ядерном 64-гигабайтном сервере ОЗУ, при этом пользователи 40-50 тыс. Обращаются к ней ежедневно до нескольких раз в минуту (каждый) в течение дня.
Мрденный

3

Это действительно невозможно оценить, не зная ничего о конкретных выполняемых вами запросах, схеме базы данных и ее размере.

Простой SELECT для индексированного столбца - это совсем не то же самое, что пара JOIN, основанных на неиндексированных ... и, конечно, многое изменится, если задействованные таблицы содержат 1K записей или 1M.

Также:

  • Какая у вас текущая аппаратная конфигурация?
  • Сколько мощности (ЦП, ОЗУ, дисковый ввод / вывод) использует ваш сервер при текущей нагрузке?

на самом деле у меня есть сервер с 2x четырехъядерным процессором с 8 ГБ оперативной памяти. я использую полный оперативной памяти и 100% процессора (кажется, я могу использовать 800%, см. здесь :) процессор: img834.imageshack.us/img834/3483/downloadv.png оперативной памяти : img442.imageshack.us/i/ download2p.png диск: img213.imageshack.us/i/download1x.png спасибо

Основываясь на этих графиках, вы используете только одно (или самое большее два) ядра вашего процессора; так что ваше приложение определенно не связано с процессором ... или оно есть, но оно не способно использовать преимущества нескольких процессоров. Кроме того, вся эта память, используемая для «кэширования», на самом деле никому не нужна , она просто используется ОС, потому что «она есть».
Массимо

Как я могу найти информацию об использовании всех ядер процессора? я использую лампу ...

Прежде всего, вы должны проверить, не используете ли вы их, потому что они просто не нужны (= низкая нагрузка), потому что ваши операции не могут быть правильно распараллелены, или потому что ваши MySQL и / или Apache не настроены на используй их. И, поскольку эти две программы обычно являются многопоточными по умолчанию, я бы посмотрел на загрузку вашего сервера и на ваши SQL-запросы ...
Massimo

3

Как заметил Игнасио, вы можете заняться кэшированием. В CMS или, возможно, даже перед стеком. 50+ запросов для каждой (каждой!) Страницы - это действительно много.


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

4
Есть очень мало незашифрованных сайтов; если он меняется только каждую секунду, вы все равно можете кэшировать целую секунду, например, 10 просмотров страниц ;-) Рассматривали ли вы не кэширование страниц целиком, а блоки или конкретные значения и т. д.? Вы можете кэшировать вне базы данных, на сегменты разделяемой памяти, файловой системы, memcached. Также, как правило, в такой ситуации ESI может быть полезным
Joris

0

Судя по вашим комментариям, самым большим фактором будет размер вашего набора данных или, по крайней мере, размер «горячего» набора данных. 3000qps или даже 8000qps на 16-ядерном сервере вообще не проблема, поскольку серверу редко приходится обращаться к диску для удовлетворения запроса. Как только активный набор данных превысит объем памяти, который InnoDB использует для его кэширования, ваша производительность быстро снизится.


0

Для больших «горячих» наборов данных, вероятно, стоит потратить время на преобразование в схему «больших данных», это то, для чего они нужны. Например, если у вас есть огромное количество данных для извлечения, но вы никогда не переписываете, а только добавляете новые данные, посмотрите на Apache Hive. Просмотрите их, как правило, это тот аромат, который вы можете достаточно легко связать с существующим кодом, что также предотвратит изжогу исчерпания пространства кеша.


0

Слишком много вещей может повлиять на ваши запросы в секунду, пожалуйста, не доверяйте моим данным, не проверив себя. Я опубликую свой результат теста скорости здесь, чтобы помочь кому-то оценить qps с текущей базой данных и машиной mysql (2018-09). В моем тесте размер данных меньше, чем объем памяти сервера (что значительно снижает количество операций ввода-вывода и значительно повышает производительность).

Я использую один процессор 3.75 ГБ памяти, 100 ГБ ssd, экземпляр сервера MySQL gcp cloud и получаю:

  • 1 клиент, один sql одна строка прочитано: 799 sql / second.
  • 50 клиентов, один sql одна строка прочитано: 6403 sql / second.
  • 50 клиентов, один sql один ряд записи: 4341 записанных строк, qps. 4341 кв / сек.
  • 1 клиент, запись 30k строк на sql: 92109 записанных строк / с.

запись результатов теста qps (2018-11) gcp mysql 2cpu 7.5 ГБ памяти 150 ГБ ssd-сериализация запись 10 потоков, запись строк 30 КБ на sql, таблица 7.0566 ГБ, длина ключа данных составляет 45 байтов и длина значения 9 байтов, получается 154 КБ записанных строк в секунду, процессор 97,1% пишет QPS 1406 / с в консоли GCP.
бронзовый человек
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.