Я запускаю более или менее стандартную установку Postgresql, которая работает очень медленно.
Я разбираю целую кучу файлов журналов с помощью Perl и использую Perl-интерфейс DBI (подключающийся к базе данных через IP-адрес 127.0.0.1) для добавления данных в базу данных. В моей базе данных около 4 таблиц. Мой сценарий в основном проверяет, существуют ли уже нормализованные данные. Если данные не существуют, он добавляет их в базу данных. В противном случае он извлекает ключи для обновления других таблиц.
Я работаю на более или менее настольном оборудовании с 2 ГБ ОЗУ, но я не ожидал, что через 5 дней добавится около 12 миллионов строк.
PS. Я увеличил размер моих shared_buffers до 25% моей оперативной памяти, но это не имело большого значения.
Любые советы будут оценены.
Изменить: я использую Ubuntu Linux
Я написал сценарии, чтобы делать именно то, что вы делаете (основная причина - анализ файлов журналов из кеша Squid). Запросы, которые вы выполняете, вероятно, довольно простые, и, если у вас нет суррогатных первичных ключей, следует использовать имплицитный индекс первичного ключа. Вы всегда можете «ОБЪЯСНИТЬ АНАЛИЗ» свои запросы, чтобы убедиться, что похоже, что они делают то, что вы ожидаете.
Базовый анализ производительности - ваша первая задача. Вы не упоминаете ОС, на которой работаете, поэтому я не могу дать вам подробных инструкций, но вы должны использовать базовые функции мониторинга производительности ОС, чтобы определить, где вы узкое место (ЦП, I / О, подкачка памяти и т. Д.). Даже простые инструменты, такие как «верх» и «Диспетчер задач», могут быстро дать вам представление.
Следующая остановка - профилирование вашего сценария. Выясните, на что сценарий тратит большую часть своего времени, и оптимизируйте эти части.
Предполагая, что значения, которые ваш сценарий извлекает из базы данных, не будут меняться во время выполнения сценария, вы можете рассмотреть возможность кэширования данных, полученных во время выполнения. Например, с помощью суррогатных первичных ключей вы можете кэшировать естественный ключ для сопоставления суррогатного ключа в ассоциативном массиве во время выполнения сценария и сохранять повторяющиеся запросы к базе данных для тех же значений. Я считаю, что это обычно большая победаTM.