FreeBSD + PostgreSQL: тюнинг сервера БД

То, что вы разбираетесь в PostgreSQL, заслуживает уважения.
На презентации Яндекса была шутка о том, что в России есть специалисты по PostgreSQL, и оба они работают в Яндексе :)

Спасибо большое! Интересно что из вышеперечисленного можно применить к mysql?

Спасибо за статью, автор! Правда, встречаются слишком очевидные вещи. Те, кто все таки юзает фряху, наверняка сами знают как запустить демон постгреса ;)

Да, тюнинг фрюхи смешной. :) Про постгресс немного интереснее. ;)

Зачим ядро пересобирать дарагой, а? сись-ка-тэ-эл шайтанама и проблема нема, э?

Хозяйке на заметку:
Вместо пересбора ядра, достаточно лишь выкрутить соответствующие sysctl'и:
kern.ipc.sem*
kern.ipc.shm*

Кстати, советую кодировку для пользователей системы выбрать UTF-8. Меньше будет проблем с PostgreSQL.

work_mem в 1/20 RAM;

Зачем так много? Какой-нибудь неправильный запрос и в своп уйдете.

The normal guidance for work_mem is to consider how much free RAM is around after shared_buffers is allocated (the same OS caching size figure needed to compute effective_cache_size), divide by max_connections, and then take a fraction of that figure; a half of that would be an aggressive work_mem value. In that case, only
if every client had two sorts active all at the same time would the server be likely
to run out of memory, which is an unlikely scenario.

думаю вот это поможет в дальнейшем изучении постгреса

не понятно, какой результат всей этой работы? на сколько выросла производительность — 1%? 10%? 100%? 1000%? может достаточно было поставить всё по умолчанию и разницы бы никто не заметил?

Судя по max_fsm_pages у вас PostgreSQL 8.3 или более ранняя версия. Я бы для новых установок рекомендовал 9.0, текущая версия 9.0.4 достаточно стабильная для использования в production.

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

Хороший обзор тюнинга сервера приведен в книжке Грэга Смита (Greg Smith):
www.packtpub.com/postgresql-90-high-performance/book

Статья Грэга в PostgreSQL Wiki:
wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Скажите, а почему бы не генерировать «на год вперед» таблицы, а проверять существование таблицы прямо в триггере и, при необходимости, создавать ее? Имена таблиц у вас в определенном формате, т.к. скрипт по крону, то производительность высокая, вероятно, не нужна и на тормоза инсерта (может, все ваше if'ы сработают быстрее, конечно, не тестил) будет пофиг и можно использовать что-то вроде:

CREATE TABLE measure_data_master(
     measure_time TIMESTAMP NOT NULL DEFAULT NOW(),
     message TEXT
); 

затем триггер:

CREATE OR REPLACE FUNCTION measure_insert_trigger() RETURNS TRIGGER AS $$
DECLARE
    tbl_name TEXT;
    d_start DATE;
    d_stop DATE;
BEGIN
    SELECT INTO tbl_name TO_CHAR(DATE_TRUNC('week', NEW.measure_time), '"measure_data_y"YYYY"m"MM"d"DD');
    IF NOT EXISTS(SELECT * FROM pg_tables where tablename = tbl_name) THEN
        SELECT INTO d_start TO_CHAR(DATE_TRUNC('week', NEW.measure_time), 'YYYY-MM-DD');
        SELECT INTO d_stop TO_CHAR(DATE_TRUNC('week', NEW.measure_time + INTERVAL '6 DAYS'), 'YYYY-MM-DD');
        EXECUTE 'CREATE TABLE '||tbl_name||'(CHECK (measure_time >= '''||d_start||''' AND measure_time < '''||d_stop||''')) INHERITS(measure_data_master);';
        EXECUTE 'CREATE INDEX '||tbl_name||'_key ON '||tbl_name||'(measure_time);';
    END IF;
    EXECUTE 'INSERT INTO '||tbl_name||' VALUES ('''||NEW.measure_time||''','''||NEW.message||''');';
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER insert_measure_trigger BEFORE INSERT ON measure_data_master FOR EACH ROW EXECUTE PROCEDURE measure_insert_trigger(); 

Минусы: падает скорость, особенно если таблицы еще не было; в триггере нужно перечислить поля таблицы (и при изменениях в ней поменять код триггера).

Да, и еще. Чтобы "… серверу БД при запросе придется шерстить не всю большую таблицу, а несколько маленьких, попавших в выбранный временной промежуток..." надо выставить параметр constraint_exclusion = ON.

postgresql.leopard.in.ua/ — добавьте ссылочку там где про книгу упоминаете, чтоб понятно было что за книга

> max_connection = 256;
а вы уверены что это хотябы рядом стояло с оптимизацией???

возьмите табличку на 100 000 000 записей или более, чтоб она весила больше Shared Memory раза в 2-3. и сделайте параллельно 256 выборок по индексу с фильтром и лимитом в сотню строк… т.е. обеспечте выборку со всех частей таблицы(в реальной жизни это почти всегда так)

как вы думаете, как скоро вы получите результат?

Прежде чем писать столь эмоциональные посты, рекомендую вникнуть в контекст, а не вырывать цитаты из цельного текста.

Классная статья.
НО почему так не любим родной язык? Какой оунер?
owner — владелец, хозяин.

CREATE TABLE measure_data_y2011m06d06 (CHECK(measure_time = DATE '2011-06-06' AND measure_time DATE '2011-06-13')
) INHERITS (measure_data_master);

CHECK(measure_time = DATE '2011-06-06' AND measure_time DATE '2011-06-13')

Мне кажется или тут закралась ошибка?