на тестовой машине под вин8 запускаю бэкап базы
1. долго делается
2. ОС тормозить жутко начинает

Это нормально?

ОС/сервер БД расположены на ссд диске

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

отредактировать строчек 6 не значит переписывать!

http://infostart.ru/public/94627/

http://megit.ru/index.php/allinfo/97-software/1c/151-gilev-1s-i-postgesql

тут правда под линь, но один хрен!

(2) ?

(3) там про установку

http://ruhighload.com/index.php/2009/05/01/настройка-и-оптимизация-параметров-postgresql/

(2) Количество строчек зависит от глубины и аспектов тюнинга. Некоторые и двумя обходятся.

(6) shared_buffers предлагаешь увеличить ?

В практических условиях это значение следует установить в 15..25% от всей доступной оперативной памяти. (с)

у меня 4 от 16 ГБт

у меня 32МБ
текущее значение 4096

RAM 32 МБ??? Всего??? о_О

всего 16 ГБ

я вот про что

http://savepic.su/5467418.png

Попробуй:
shared_buffers = 2GB
work_mem = 128MB
maintenance_work_mem = 1GB
effective_cache_size = 4GB

(15) включил

вроде не тормозит

блин -- а как обратно откатить конфу ?

(18) в каком смысле?

(18) Это текстовый файл. Варианты:
- делай бэкап
- открой в блокноте и верну вручную "взад"

видео на ютубе тормозит, когда бэкап деалется

(21) Ютуб - это очень важная процедура, важнее бекапа. ))

(22) это же не нормально, что тормозит

(23) Ну, попробуй уменьшить приоритет CPU на задачи постгри, если десктоп в приоритете. Серверные задачи плохо дружат с декстопными. Это разные схемы использования ресурсов.

(20) вот забыл сделать (((

Особенности использования PostgreSQL 8.2

В PostreSQL 8.2 изменена работа оптимизатора существенно зависит от размера выделенной PostreSQL оперативной памяти. При использовании PostgreSQL 8.2 при работе с 1С:Предприятием 8 рекомендуется увеличить значение параметра effective_cache_size в конфиргурационном файле postgresql.conf. Значение этого параметра рекомендуется устанавливать не менее половины объема оперативной памяти установленной на компьютере.

Оптимизация производительности PostgreSQL

Ниже перечислены основные параметры, на  которые следует обратить внимание при оптимизации производительности PostgreSQL.

shared_buffers

Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц (shared_buffers) по 8 килобайт каждая. Следует учитывать, что операционная система сама кеширует данные, поэтому нет необходимости отводить под кэш всю наличную оперативную память. Размер shared_buffers зависит от многих факторов, для начала можно принять следующие значения:

8–16 Мб  – Обычный настольный компьютер с 512 Мб и небольшой базой данных
80–160 Мб – Небольшой > сервер, предназначенный для обслуживания базы данных с объёмом оперативной памяти 1 Гб и базой данных около 10 Гб.
400 Мб – Сервер с несколькими процессорами, с объёмом памяти в 8 Гб и базой данных занимающей свыше 100 Гб обслуживающий несколько сотен активных соединений одновременно .
work_mem

Под каждый запрос выделяется ограниченный объём памяти для работы. Этот объём используется для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно снизить производительность. Оценить необходимое значение для work_mem можно разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buffers) на максимальное число одновременно используемых активных соединений.

maintenance_work_mem

Эта память используется для выполнения операций по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске.

effective_cache_size

PostgreSQL в своих планах опирается на кэширование файлов, осуществляемое операционной системой. Этот параметр соответствует максимальному размеру объекта, который может поместиться в системный кэш. Это значение используется только для оценки. effective_cache_size можно установить в 1/2 - 2/3 от объёма имеющейся в наличии оперативной памяти, если вся она отдана в распоряжение PostgreSQL.

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

fsync

Данный параметр отвечает за сброс данных из кэша на диск при завершении транзакций. Если установить его значение fsync=off то данные не будут записываться на дисковые накопители сразу после завершения операций. Это может существенно повысить скорость операций insert и update, но есть риск повредить базу, если произойдет сбой (неожиданное отключение питания, сбой ОС, сбой дисковой подсистемы).


synchronous_commit

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

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

Решение проблемы с зависанием PostgreSQL

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

Варианты решения проблемы:

Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполения команды ANALYZE, но улучшат построение плана запроса:
Файл postgresql.conf - default_statistics_target = 1000 -10000.
Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
Файл postgresql.conf - enable_nestloop=off.
Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
Файл postgresql.conf - join_collapse_limit=1.
Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
Изменение параметров настройки оптимизатора:
Файл postgresql.conf:
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025
Использование версии PostgreSQL 9.1.2-1.1.C, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций можно включить сбор статистики для всех  или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL( файл postgresql.conf) online_analyze.table_type = "temporary"  на online_analyze.table_type = "all".
После изменнеия этих параметров, следует оценить возможное влияние этих изменений на работу системы и выбрать наиболее приемлимый выриант для ваших задач.

shared_buffers - я ставил в половину оперативки. Определяет сколько БД будет держать в оперативке.
effective_cache_size в пару раз меньше. этот параметр не очень помогал работе.

Есть еще такие параметры как Checkpoints
PG вначале пишет в сегменты, а уже потом скидывает все в базу. по сути что-то типа дискового кэша. Если быстро забивается - начинается просадка производительности жуткая.

(29) благодарю, буду иметь ввиду

удалил постгрис, чтобы заново понять из-за чего тормоза

при установке сменил логин суперпользователя с postgres на sa

а где теперь в pgAdmin III указывать логин, т.к. там просит при подключении к БД пароль для логина postgres ?

(31) нашёл =)

Недавно заметил, что при включенном enable_nestloop отчет по основным средствам в БГУ формируется около двух минут, зато главная книга - около 30-ти секунд. Если сделать enable_nestloop=off, то 15 секунд и 4 минуты соответственно. Так что включать/не включать зависит от того, что более  актуально в обычной, текущей работе

(15) что-то я не пойму

зачем менять эти параметры, если сейчас они в следующем состоянии (после установки с нуля) и что такое "текущее значение" ?


shared_buffers
значение = 32 МБ текущее значение = 4096 МБ (это 4 ГБ)

work_mem
значение = 1 МБ текущее значение = 1025 (это 1 ГБ)

maintenance_work_mem
значение = 16 МБ текущее значение = 16384 (это 16 ГБ)

effective_cache_size
значение = 512 МБ текущее значение = 65536 (это 64 ГБ)

(34) Предполагаю, что "Значение" - это то, что прописано в конфигурационном файле. А "Текущее значение" - те настройки, которые сейчас действуют на сервере.
И предполагаю, что текущие значения без явной приписки единицы измерения - даны в килобайтах. Так что ты не совсем прав в оценках.

(35) а где это по-подробнее можно узнать ?

(36) http://www.postgresql.org/docs/

Но не дам гарантий, что там есть эта информация. Скорее, либо в документации по утилите администрирования, либо вообще нигде.

Но я бы исходил из (35). Похоже, что что-то мешает установке максимальных значений памяти, прописанных в конфигурации, либо что-то еще на это влияет. В линухе это ограничивается одним из параметров ОС, а как в виндовой версии - хз...
Т.е. work_mem и maintenance_work_mem совпадают, а shared_buffers и effective_cache_size соответственно в 4МБ и 64МБ у тебя стоят. Для начала попробуй просто рестартануть сервер, а если ничего не изменится - тогда гуглить.

(37) вот что нашёл

Numeric with Unit: Some numeric parameters have an implicit unit, because they describe quantities of memory or time. The unit might be kilobytes, blocks (typically eight kilobytes), milliseconds, seconds, or minutes. An unadorned numeric value for one of these settings will use the setting's default unit, which can be learned from pg_settings.unit. For convenience, settings can be given with a unit specified explicitly, for example '120 ms' for a time value, and they will be converted to whatever the parameter's actual unit is. Note that the value must be written as a string (with quotes) to use this feature. The unit name is case-sensitive, and there can be whitespace between the numeric value and the unit.

http://www.postgresql.org/docs/current/static/config-setting.html

правильно я понял, что если единицы не указывается, то она берется из pg_settings.unit ?

Вроде как бы да, но непонятно имеет ли этот блок документации отношение к виндовой утилите администрирования.

(41) и где главное в винде pg_settings.unit =)

И вообще к размерности действующих значений на сервере. Это скорее к формату УСТАНОВКИ параметров.

сделал сейчас следующее :

изменил
shared_buffers на 8 ГБ
после перезапуска сервера текущее значение стало равно 65536, т.е. если это разделить на 1024 = 64
а было 4096, т.е. в 16 возрасло

значит в текущем значении отражаются кБ

+ (44) видео на ютубе перестало тормозить

хотя нет +(45) видео тормозит

Вот и effective_cache_size у тебя упирается в 64МБ, хотя должно быть 512. Что-то не пускает.

В линухе это параметр kernel.shmmax
Может, они его как-то хитро на винду портировали...

(47) так может это не в нагруженном состоянии ?

Это параметр именно линуха, не постгри.

(49) Если по аналогии с линкусовой версией - то вряд ли. Должно отображать именно доступное постргри, а не загрузку.

(42) В psql набрать select * from pg_catalog.pg_settings;
Получится таблица с такими колонками http://www.postgresql.org/docs/9.1/static/view-pg-settings.html по каждому параметру.

(51) да уж

(52) Ключевое слово было "unit"

(54) select name,setting,unit from pg_catalog.pg_settings;
Или так.

установил вот такие параметры

shared_buffers = 2GB
work_mem = 128MB
maintenance_work_mem = 1GB
effective_cache_size = 8GB

всё равно тормоза

а диски какие?

(57) ссд

full_page_writes = off
Ну и fsync тоже можно, машина же тестовая.

(58)железнячникам думаю будет интересна модель

+ (58)

SSD 512 Gb SATA 6Gb / s Crucial M550 < CT512M550SSD1 > 2.5" MLC

Скорость чтения    До 550 Мб/сек
Скорость записи    До 500 Мб/сек

http://www.nix.ru/autocatalog/ssd_crucial/SSD_SATA_6Gb_Crucial_M550_CT512M550SSD1_MLC_184835.html

(56) Так а толку? Выяснили же, что эти параметры не применяются.

(0) а запускаешь бэкап собсно в какую сторону? cf -> db, db -> dt, dt -> db?

просто обращал внимание, что при загрузке cf 1с делает 17 тысяч запросов select и столько же insert/update + autocommit, т.е. всю таблицу перебирает по одной строчке, и делать это может до утра, т.к. на таблицу навешана гора индексов

а если делать загрузку из dt, то тупо перезаливается вся таблица в считанные минуты, в конце один autocommit

(62) сейчас текущее значение effective_cache_size
1048576

1048576 = 1024 * 1024

А shared_buffers?

Хотя я тут х.з. Ютуб ведь может тормозить и при нормальной работе постгри. Значит, постгри эффективно использует ресурсы :)

(66) текущее 4096

(67) тормоза ютуба, как только я ставлю на архивацию
как-то только архивирование закончится или я принудительно сниму задачу -- видео сразу нормализуется

(68) Т.е. 4МБ
Очень подозрительно. Если тормоза из-за свопа, то это оно.
(69) CPU во время архивации ощутимо нагружается?

(70) в диспетчере задач смотреть ?

(71) лучше в procexp
и таки ответь на (63)

(72) нажимаю правой кнопкой на базу в постгрис и сохраняюю

(73) чо? (c)

sql базу из pgadmin3 чтоли? без участия 1с?
если так, то он pg_dump вроде напрямую запускает, не должно ничего сильно тормозить

разве что поставил галочку "Use Insert commands" (--inserts)

если жалоба только на ютуб - то все нормально, он и будет заикаться при полностью занятом IO

в любом случае посмотри procexp

(74) pgadmin3

(75) тогда все в порядке, не мешай машине работать

(76) разве нормально, когда в pgadmin3 делают бэкап всё начинает виснуть ?

(77) pg_dump, особенно запущенный с форматом custom, делает одну очень простую вещь:
читает таблицу из файла базы на диске и пишет эту таблицу в файл дампа на диске,
процессорное время при этом практически не тратит. Эффективность использования каналов IO при этом близка к 100%. Соответственно, количество времени, в которое процессор может работать в обычном режиме - близко к 0%.

Отвечая на твой вопрос - да, это нормально, с учетом того, что ты серверное ПО запускаешь на ноутбуке с виндовсом.

автоархивация через планировщик настраивается ?

(78)Если все тормоза из-за чтения/записи на диск, то лучше было бы бэкап настроить на другой физический диск или устройство? И, вообще, бекапить на другое устройство, по моему, более правильно.