Почему DBS не адаптирует / не настраивает размер буфера автоматически? - PullRequest
0 голосов
/ 10 декабря 2010

Не уверен, что нет DBS, которая делает, и действительно ли это полезная функция, но: Есть много предложений о том, как ускорить операции с БД путем настройки размеров буфера.Одним из примеров является импорт данных Open Street Map (файл планеты) в экземпляр Postgres.Для этой цели существует инструмент osm2pgsql (http://wiki.openstreetmap.org/wiki/Osm2pgsql)), а также руководство, которое предлагает адаптировать определенные параметры буфера для этой цели. На последнем этапе импорта база данных создает индексы и (согласно моему пониманию при чтенииdocs) выиграл бы от огромного maintenance_work_mem, тогда как при нормальной работе это было бы не слишком полезно. Этот поток http://www.mail-archive.com/pgsql-general@postgresql.org/msg119245.html внаоборот, предполагает, что большое значение maintenance_work_mem не будет иметь особого смысла во время окончательного создания индекса. В идеале (imo) DBS должна лучше знать, какую комбинацию размеров буферов она может получить больше всего, учитывая ограниченный размер общей буферной памяти. Итак, есть ли веские причиныпочему нет встроенной эвристики, способной автоматически адаптировать размеры буфера в соответствии с текущей задачей?

Ответы [ 2 ]

0 голосов
/ 10 декабря 2010

Проблема такая же, как с любым программным обеспечением для прогнозирования. То, что исторически что-то произошло, не означает, что это случится снова. Кроме того, вам необходимо выполнить задачу, чтобы полностью проанализировать, как вы должны были сделать ее более эффективной. Проблема в том, что следующая задача не обязательно похожа на ранее выполненную задачу. Итак, если вашей процедуре импорта нужно 8 ГБ памяти для завершения, имеет ли смысл назначать каждому пользователю только для чтения 8 ГБ памяти? Обратный путь тоже не сработает.

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

Другим важным аспектом является то, что большинство людей / компаний ценят надежные и стабильные уровни на разных, но потенциально более высоких уровнях. Высокая стоимость не так важна, как большие различия в стоимости. Это, конечно, не всегда так, поскольку целые компании основаны на том факте, что время от времени этот показатель достигает 1%.

Современные базы данных уже прилагают некоторые усилия для адаптации к представленным задачам, таким как все более и более изощренные оптимизаторы запросов. По крайней мере, у Oracle есть возможность отслеживать некоторые меры, влияющие на решения оптимизатора (стоимость чтения одного блока, которая будет зависеть от текущей нагрузки).

0 голосов
/ 10 декабря 2010

My думаю, было бы ужасно трудно правильно настроить ручки с помощью адаптивных средств.Сначала вам нужно будет запросить у машины много неизвестных, например, сколько у нее оперативной памяти, а также неизвестное «что вы ожидаете дополнительно запустить на машине».

Запрет на это, установивТолько для параметра max_mem_usage проблема состоит в том, как создать систему, которая

  • хорошо адаптируется к большинству типичных нагрузок.
  • Не возникает странных патологических проблем с некоторыми нагрузками.
  • - несколько понятный код без ошибок.

Однако для postgresql ответ также может быть

  • Никто еще не написал его, потому что другие вещи считаются более важными..
  • Вы еще не написали.
...