#postgresql #performance #database-replication
#postgresql #Производительность #база данных-репликация
Вопрос:
Мне пришлось переопределить описание проблемы.
У меня облачная база данных PostgreSQL, выполняющая 1,5 млн запросов в день. Я проверил статистику самих отдельных запросов с различными вариантами извлеченных данных. В целом, с отдельными запросами все в порядке (они действительно просты и вряд ли будут задерживаться). Проблема возникает во время работы приложения. Приложение представляет собой интернет-игру. Во время одной игровой сессии в базу данных постоянно записываются новые записи (с текущим состоянием игры). В это время выполняется много вставок. Пользователь может захотеть просмотреть историю игры в любое время (пока выполняются такие вставки). На этом этапе, когда служба записи добавляет новые записи в базу данных, служба чтения считывает данные. Такое чтение встречается очень редко по сравнению с записью, оно происходит в соотношении 1:100 (но в будущем такое чтение будет происходить чаще). Служба ugh-read обычно считывает данные за 0-6 секунд. Иногда время чтения увеличивается до 40 или даже 100 секунд. Редкие скачки, такие как 10-20 секунд, были бы приемлемы, но мне абсолютно необходимо избавиться от скачков более 40 секунд. Для этой конкретной проблемы я думаю о репликации MASTER-SLAVE (только для записи-только для чтения)
Дополнительная информация: комментатор спросил о:
- Облачный сервис: gcp
- Ограничение на обслуживание: ограничения: память: 1500 Мбайт процессор: 500 мбайт
- Версия Postgres: 10
Если было бы хорошо, я мог бы представить структуру запросов и таблиц. Все написано весной.
Комментарии:
1. Да, и 1% — это чтение, 99% — запись на данный момент.
2. Что ж, если считывается только 1% всех запросов, то перемещение их на другой сервер вам не очень поможет. Вам нужно будет найти способ оптимизировать запись. Но этот вопрос слишком широк для Stackoverflow.
3. Итак, есть ли у вас какие-либо советы о том, где мне следует искать помощь и решения?
4. Списки рассылки , вероятно, были бы хорошим началом. Но вам также придется предоставить гораздо больше деталей, если вы хотите инициировать хорошее обсуждение (в которое оно превратится — это не так просто, как «FAQ»)
5. Спасибо, что вы думаете о таком сообщении в разделе «Администраторы баз данных» на «StackExchange»?
Ответ №1:
Проще говоря, вам нужно найти и устранить узкое место.
Несколько советов:
-
Посмотрите на операционную систему и посмотрите, как работают система ввода-вывода и процессор.
-
Уменьшите количество одновременных подключений к базе данных, возможно, используя пул подключений.
-
Используйте
pg_stat_statements, чтобы найти инструкции, которые вызывают наибольшую нагрузку.
Комментарии:
1. Большое вам спасибо, я попробую эти указатели. Но что вы вообще думаете об идее реплики в этом случае? Помогает ли это в таких ситуациях?
2. Это невозможно сказать, потому что вы не указали никаких точек данных. Но моя интуиция заключается в том, чтобы бороться с причиной проблемы, а не тратить деньги и усилия на обходной путь, прежде чем вы поймете проблему.
3. Я отредактировал сообщение и добавил некоторую информацию, потому что я понял свою проблему по-другому, я думаю, это многое меняет. Не могли бы вы взглянуть еще раз?