[quot Andron]Maxim Bogukпропущено...


Так давайте определимся что кэш ФС является посредником между диском и структурой PostgreSQL которая определяется через параметр shared_buffers. Т.е. вначале данные запрашиваются пользователем в базе, затем PostgreSQL если их не находит в shared_buffers то читает с диска, но не напрямую а используя посредника - кэш ФС. И данные эти опят таки помещает из кэша ФС в shared_buffers для дальнейшей обработки и передачи пользователю. Еще раз выделю свое предположение: PostgreSQL не управляет данными в файловом кэше ОС, только в кэше определенном как shared_buffers. Если это так то имеем интересное следствие с т.з. производительности дискового IO.

Самое интересное следствие выходит если отдать около 50% под shared buffers. В итоге есть шанс получить ситуацию когда у вас данные лежат в 2х местах в памяти и эффективный размер кеша будет половина от наличной памяти.

Из этого следует что по хорошему под shared buffers имеет смысл отдавать или 20-25% или 75-80% наличной памяти (предполагая что сервер выделен исключительно под базу). Из моего опыта оба варианта на 8.3+ вполне работоспособны а какой из них даст большую производительность очень сильно зависит от конкретного проекта.

AndronMaxim Boguk,

Вообще напрашивается такой вопрос: а зачем дополнительно кэшировать данные базы, ведь это приводит к накладным расходам и снижению надежности. Кажется это называется Direct IO и как раз позволяет избежать использования кэширования на уровне ОС в случае использования файлов для базы. Речь идет именно про файлы а не raw device, с которыми подобной проблемы не возникает, но и PostgreSQL их не поддерживает вроде бы.

До 8.3 Postgres очень плохо работал с обьемами shared memory большими чем 1gb. Поэтому так или иначе приходилось использовать кеш ОС.

Сейчас эта проблема устранена в основном (не до конца на самом деле... остались некоторые внутренние накладные расходы которые линейно от обьема shared memory растут), и разговоры о direct IO ведутся но общее мнение разработчиков таково:
текущая схема работы работает вполне прилично и пока никто еще не предоставил test case и результаты где бы direct IO давало бы выйгрыш в скорости работы и смысла в этом направлении двигатся нет (во всяком случае пока нет спонсоров которые бы это оплатили).

К модератору:
если вас не затруднит, пожайлуста, отделите вопросы касащиеся shared buffers/direct IO из этой темы в отдельную.

AlexeyNP Andron

Если ты думаешь, что люди делающие PG делают что-то не так - возьми и помоги, если есть острое желание, время, силы и знания. Что сложного? Вот Maxim Boguk так и поступил.

Maxim Boguk
Насколько добавляется I/O при таком, ленивом вакууме?
Можно как-то лимитировать по этому параметру?
Насколько оцениваете надежность - на фронтальной базе запустить можно?
А то опять эти дампы-копи-пасты между 4-мя серваками :(



IO добавляется приблизительно столько же сколько от vacuum full было бы (+/- 2 раза от ситуации в таблице зависит).
По IO лимитировать можно... смотрите параметры:
--pages-per-round= (сколько страниц чистить за 1 цикл вызова хранимки) по умолчанию 10
--delay= (сколько в секундах ждать после каждой пачки в --pages-per-round принимает float по умолчанию - 0)
--delay-ratio - наиболее полезный для целей лимитирования нагрузки параметр... работает он следующим образом: смотрится за сколько обработалось последняя --pages-per-round= пачка страниц, после спит (время обработки предыдущей пачки)*--delay-ration времени, умолчательное значение 2 (это позволяет одному и тому же скрипту нормально работать и в пиковую нагрузку и ночью в минимуме нагрузки... так как чем медленее идет основной процесс тем больше будут паузы между вызовами... я в при эксплуатации видел до 10 раз разницы в скорости между дневной и ночной работой).

Умолчательные настройки (не быстро но не создавая большой нагрузки на сервер):
--pages-per-round=10 --delay-ratio=2
Настройки упаковать любой ценой максимально быстро:
--pages-per-round=100 --delay-ratio=0
(ставить больше 100 в --pages-per-round=100 не стоит начинаются накладные расходы и с 1000 уже в 1.5 раза медленее идет... меньше 10 тоже не стоит ставить пока нет реализации через DBD::Pg или managed psql).

Обязательно стоит посмотреть на то чтобы у вас vacuum_cost_delay был в базе так настроен чтобы вызов vacuum не вызывал перегрузки дисковой системы, так как скрипт в процессе работы делает обычный vacuum таблицы до 20 раз.

Система тестировалась на ОЧЕНЬ нагруженных базах моих клиентов (список тут: http://mboguk.moikrug.ru/) на очень разных серверах и структурах таблиц. Проблем выявлено не было (лучше не забывать делать svn up перед использованием так как выявленные сложности я оперативно исправяю).

Потери или повреждения данных не было ни разу, 1 раз возникла перегрузка дисковой системы в дневное время (после чего собственно и появилась автоподстройка нагрузки через --delay-ratio).

Комментарии по результатам использования приветствуются.