Оптимизация запросов PostgreSQL и процесс Postmaster ' - PullRequest
Новая
       32

Оптимизация запросов PostgreSQL и процесс Postmaster '

1 голос
/ 05 января 2009

В настоящее время я работаю с базой данных PostgreSQL, полученной из wikipedia-dump; он содержит около 40 ГБ данных. База данных работает на сервере HP Proliant ML370 G5 с Suse Linux Enterprise Server 10; Я запрашиваю его со своего ноутбука через частную сеть, управляемую простым маршрутизатором D-Link. Я назначил статические DHCP (частные) IP-адреса как ноутбуку, так и серверу.

В любом случае, с моего ноутбука, используя pgAdmin III, я отправляю некоторые команды / запросы SQL; некоторые из них: CREATE INDEX, DROP INDEX, DELETE, SELECT и т. д. Иногда я отправляю команду (например, CREATE INDEX), она возвращает сообщение о том, что запрос был выполнен отлично и т. д. Однако процесс postmaster назначен такому Кажется, команда остается спящей на сервере. Теперь я не против этого, поскольку говорю себе, что PostgreSQL поддерживает пул мастеров, готовых обрабатывать запросы. Тем не менее, если этот процесс израсходует 6 ГБ из этого 9,4 ГБ, выделенного ОЗУ, я беспокоюсь (и это происходит на данный момент). Теперь, возможно, это кэш данных, который хранится в [общей] памяти на случай, если другой запрос потребует использовать те же данные, но я не знаю.

Еще одна вещь беспокоит меня.

У меня есть 2 таблицы. Одним из них является таблица page ; У меня есть индекс в столбце page_id . Другой - это таблицы pagelinks , в которых есть столбец pl_from , который не ссылается ни на что, или на переменную в столбце page.page_id ; в отличие от столбца page_id , pl_from не имеет индекса (пока). Чтобы дать вам представление о масштабе таблиц и необходимости найти жизнеспособное решение, в таблице page содержится 13,4 млн строк (после того, как я удалил те, которые мне не нужны), а ссылки на страницы таблица имеет 293 млн.

Мне нужно выполнить следующую команду, чтобы очистить таблицу pagelinks некоторых ее бесполезных строк: 

DELETE FROM pagelinks USING page WHERE pl_from NOT IN (page_id);

Так что, в общем, я хочу избавить таблицу pagelinks от всех ссылок, приходящих со страницы, не входящей в таблицу page . Даже после отключения вложенных циклов и / или последовательных проверок оптимизатор запросов всегда дает мне следующее «решение»: 

Nested Loop  (cost=494640.60..112115531252189.59 rows=3953377028232000 width=6)
  Join Filter: ("outer".pl_from <> "inner".page_id)"
  ->  Seq Scan on pagelinks  (cost=0.00..5889791.00 rows=293392800 width=17)
  ->  Materialize  (cost=494640.60..708341.51 rows=13474691 width=11)
        ->  Seq Scan on page  (cost=0.00..402211.91 rows=13474691 width=11)

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

Ответы [ 3 ]

1 голос
/ 06 января 2009

Действительно, я решил СОЗДАТЬ временную таблицу для ускорения выполнения запроса: 

CREATE TABLE temp_to_delete AS(
    (SELECT DISTINCT pl_from FROM pagelinks) 
        EXCEPT 
    (SELECT page_id FROM page));
DELETE FROM pagelinks USING temp_to_delete 
    WHERE pagelinks.pl_from IN (temp_to_delete.pl_from);

Удивительно, но этот запрос был выполнен примерно за 4 часа, в то время как первоначальный запрос оставался активным в течение 14 часов, прежде чем я решил его убить. Более конкретно, УДАЛЕНО вернуло: 

Query returned successfully: 31340904 rows affected, 4415166 ms execution time.

Что касается первой части моего вопроса, кажется, что процесс postmaster действительно хранит некоторую информацию в кеше; когда для другого запроса требуется информация не в кеше, а в некоторой памяти (RAM), кеш очищается. А почтмейстеры - это действительно пул процессов ».

Мне также пришло в голову, что gnome-system-monitor - это миф, поскольку он дает неполную информацию и ничего не стоит в информационной ценности. В основном из-за этого приложения я так запутался в последнее время; например, он не учитывает использование памяти другими пользователями (например, пользователем postgres!) и даже говорит мне, что у меня осталось 12 ГБ ОЗУ, когда это не соответствует действительности. Поэтому я опробовал несколько системных мониторов, так как мне хотелось бы узнать, как postgreSQL использует его ресурсы, и кажется, что xosview действительно является допустимым инструментом.

Надеюсь, это поможет!

1 голос
/ 06 января 2009

ко второму вопросу; вы можете попробовать создать новую таблицу с нужными записями с помощью оператора CREATE TABLE AS; если новая таблица достаточно мала, она может быть быстрее, но это тоже не поможет.

0 голосов
/ 28 октября 2009

Ваш процесс postmaster будет оставаться там до тех пор, пока соединение с клиентом открыто. Pgadmin закрывает соединение? Я не знаю.

Используемая память может быть shared_buffers (проверьте настройки конфигурации) или нет.

Теперь запрос. Для больших операций обслуживания, подобных этой, не стесняйтесь устанавливать для work_mem что-то большое, например, несколько ГБ. Ты выглядишь так, как будто у тебя много оперативной памяти, поэтому используй ее.

установить для work_mem значение 4 ГБ; ОБЪЯСНИТЬ УДАЛИТЬ ИЗ ссылок на страницы, ГДЕ pl_from НЕ ВХОДИТ (ВЫБЕРИТЕ page_id ИЗ СТРАНИЦЫ);

Он должен последовательно сканировать страницу, хэшировать и сканировать ссылки на страницы, заглядывая в хэш, чтобы проверить page_ids. Это должно быть довольно быстро (намного быстрее, чем 4 часа!), Но вам нужен большой work_mem для хэша.

Но поскольку вы удаляете значительную часть таблицы, это может быть быстрее, если бы вы сделали это следующим образом:

СОЗДАТЬ ТАБЛИЦУ pagelinks 2 КАК ВЫБРАТЬ a. * ИЗ СТРАНИЦ ссылки на присоединенные страницы b ON a.pl_from = b.page_id;

(вместо IN можно использовать простой JOIN)

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

...