Вопросы Теги

PostgreSQL много больших массивов и Записей

Это могло бы быть немного более тяжело, чем, что Вы ищете, но Постфиксный модуль Webmin (который является стандартным модулем) предоставит Вам инструменты, которые Вы хотите - включая способность посмотреть на очередь, посмотрите в почтовых ящиках и т.д.

0
задан 21 March 2010 в 21:58
2 ответа

effective_cache_size не изменяет настроек памяти, он использовал только в целях оценки в планировании запроса. Проверните shared_buffers приблизительно к 25% Вашей доступной RAM и посмотрите, существуют ли какие-либо различия в скорости.

Кроме того, использование ОБЪЯСНЯЮТ, чтобы получить queryplan и видеть, нужны ли Вам некоторые дополнительные индексы или лучшая конфигурация.

1
ответ дан 4 December 2019 в 15:18
  • 1
    Да, shared_buffers к 25% помогают. Спасибо –  user84590 22 March 2010 в 12:46
  • 2
    Почему бы не увеличить его до 50%? –  user84590 22 March 2010 в 22:35
  • 3
    Поскольку Вы don' t хотят уничтожить Ваш сервер. Если у Вас есть много RAM, Вы могли бы использовать больше чем 25% для shared_buffers, но осторожны. Будьте очень осторожны! PostgreSQL использует больше RAM, чем просто shared_buffers, и Вашему серверу также нужна RAM для других вещей. Для каждого соединения нужна RAM, для каждой операции вида нужна RAM, и т.д. и т.д. и т.д. То, когда Вы продвигаете его слишком много, Ваш сервер мог бы уничтожить администратора почты (ест слишком много RAM), или начинает подкачивать и уничтожать производительность. Лучший queryplan, с помощью меньшего количества RAM, мог бы быть лучшей идеей. Но that' s до базы данных. –  Frank Heikens 22 March 2010 в 23:02
  • 4
    Ясно. Когда я смотрю на вершину или dstat, я вижу 58 ГБ, используемых для кэша. Это включает и совместно использованные буферы и кэш ядра? Кажется, что это оба, потому что мои 8 процессов администратора почты используют 9 ГБ общей памяти, в то время как у меня только есть 64 ГБ поршня.? Еще раз спасибо :) –  user84590 23 March 2010 в 02:36
  • 5
    См. это изображение: postgresql.org/files/documentation/books/aw_pgsql/… И да, 58 ГБ являются всем кэшем. PostgreSQL doesn' t берут весь shared_buffers, когда он запускается, он просто берет то, в чем он нуждается до предельного набора в конфигурации. –  Frank Heikens 23 March 2010 в 10:54

Кажется ударом узкого места ввода-вывода. У Вас есть много кэш-памяти, но насколько большой набор данных? Какова текущая настройка дисков? Насколько занятый диски? Узкое место могло быть сетью?

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

Этот сайт имеет хороший обзор для настройки пост-ГРЭС.

1
ответ дан 4 December 2019 в 15:18
  • 1
    Набор данных - больше затем 60 ГБ, но Таблицы, все строки которых используются каждым SQL Функциональное взятие приблизительно 15 ГБ. Этой настройкой дисков являются 2 Массива RAID 10 4 SAS 10k об/мин 146 ГБ каждый. 15 ГБ часто используемых Таблиц находятся на первом массиве RAID 10, в то время как все остальное, включая тех, которые, чем, получает много Вставок, находятся на другом массиве RAID 10. Диски не кажутся что занятыми. Определенно не сеть. Каждый process' s использование памяти, действительно кажется, растет много, в то время как приложение прогрессирует. Что Вы предлагаете? –  user84590 21 March 2010 в 23:50
  • 2
    Необходимо проверить производительность ввода-вывода так или иначе только для исключения его как проблемы. Проверьте главным образом количество trasactions в секунды. Во-вторых, каждый рабочий пост-ГРЭС должен получить установленный объем памяти, указанной опцией конфигурации памяти работы. Попробуйте увеличение это. Отредактированный ответ также –  Dan Andreatta 22 March 2010 в 00:20
  • 3
    Та конфигурация оперативной памяти, кажется, помогла. Спасибо. –  user84590 22 March 2010 в 12:47

Теги

Похожие вопросы