Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
Есть база, в которую идёт массовая вставка записей(Delphi -> Zeos 6.6.1 -> PG 8.2.3). Пробовал делать коммит после каждой вставки, и после каждых 1000 вставок. Разница в скорости - в пределах погрешности измерения. Это нормально, или я что-то не так делаю? Дело в том, что в InterBase скорость вставок при массовом коммите сильно возрастает. Но понятно, что базы разные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 11:33 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
А вы уверены, что в ZEOS компонентах не стоит автокоммит и поэтому скорость вставки одинаковая? Возможно ваша БД настолько мала, что разница столь минимальна. При реальных нагрузках всё должно изменится не в пользу КОММИТА каждого INSERT'а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 12:21 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
Все верно. PostgreSQL после каждого коммита НЕ СБРАСЫВАЕТ данные на диск, а держит их в буфере. Вот в версии 7.4 массовый коммит был действительно необходим, а в старших версиях СУБД умнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 13:07 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
MBGВсе верно. PostgreSQL после каждого коммита НЕ СБРАСЫВАЕТ данные на диск, а держит их в буфере. Вот в версии 7.4 массовый коммит был действительно необходим, а в старших версиях СУБД умнее. Не факт. За сброс WAL буффера на диск отвечает параметр commit_delay, который может быть равен 0 и сброс будет происходить моментально после COMMIT'а. Большое значение грозит бОльшей потерей данных в случае падения БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 13:15 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
В таблице, в которую идёт инсерт - 5 млн записей В Zeos'е стоит AutoCommit := False. То, что коммит через 1000 работает - видно по базе (кол-во записей в процессе работы кратно 1000). А вот commit_delay равно 0. Но, судя по http://www.phpclub.ru/detail/store/pdf/postgresql-performance.pdf это используется для оптимизации нескольких мелких транзакций. Неужели явные begin-commit не указ? Сейчас попробую покрутить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 13:50 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
_Андрей_МВ таблице, в которую идёт инсерт - 5 млн записей В Zeos'е стоит AutoCommit := False. То, что коммит через 1000 работает - видно по базе (кол-во записей в процессе работы кратно 1000). А вот commit_delay равно 0. Но, судя по http://www.phpclub.ru/detail/store/pdf/postgresql-performance.pdf это используется для оптимизации нескольких мелких транзакций. Неужели явные begin-commit не указ? Сейчас попробую покрутить. Крутить стОит если у вас OLTP с большим кол-вом соединений. commit - это не указ сбрасывать на диск. 5 Млн записей это не показатель в данном случае. Я просто хочу сказать, чтобы вы не делали коммит после каждой вставленной строки. Лучше коммитить по 1000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 14:11 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
Установка commit_delay = 1000 удовлетворения не принесла. Как и увеличение wal_buffers с 256к до 512к. Винчестер, собственно, не напрягается, даже если коммит каждой записи делать. Тут дело в чём-то другом. Или в самом деле Pg всё оптимизирует до безобразия, и быстрее уже не получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 14:37 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
_Андрей_МУстановка commit_delay = 1000 удовлетворения не принесла. Как и увеличение wal_buffers с 256к до 512к. Винчестер, собственно, не напрягается, даже если коммит каждой записи делать. Тут дело в чём-то другом. Или в самом деле Pg всё оптимизирует до безобразия, и быстрее уже не получится. А зачем вы стали увеличивать этот параметр? В вашем примере вы добъетесь того, что конструкция с КОММИТами по одной записи будет приближаться по времени к КОММИТу 1000 ИНСЕРТов (опять же повторюсь, в реальном environtment'е!). 1000 строк это ... ну 500 - 900 Кб (отбросим часные случаи с blobами) + индексы и пр. системная информация. То есть допустим набегает что-то около 1.0 - 1.5 Мб. Что это есть для современного железа без конкурентных сессий...? Кстати, создайте на сервере ощутимую загрузку CPU + I/O и тогда сравните разницу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 15:43 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
MBGВсе верно. PostgreSQL после каждого коммита НЕ СБРАСЫВАЕТ данные на диск, а держит их в буфере. Даааа? А после случайного нажатия кнопки Reset он данные откуда достаёт --- из буфера? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 20:26 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
Thamerlan Не факт. За сброс WAL буффера на диск отвечает параметр commit_delay, который может быть равен 0 и сброс будет происходить моментально после COMMIT'а. Большое значение грозит бОльшей потерей данных в случае падения БД. А commit_delay вощемта работает в паре с commit_siblings. Если параллельно не будут работать несколько (commit_siblings) процессов, то никакой задержки не будет. У автора исходного сообщения процесс всего один, следовательно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 20:31 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
Про сброс WAL буфера слышали, а вот куда он сбрасывается - не понимаете. А сбрасывается он в журнал транзакций. И только после заполнения сегментов журнала или по прошествии определенного времени данные в файл таблицы попадают. Так что коммит транзакции вовсе не приводит к какой-то лихорадочной деятельности по записи на диск, все идет строго по плану. Между прочим, один сегмент это 16 мегабайт и при настройках по умолчанию может быть до 7 сегментов (2*checkpoint_segments+1). Перемножили? С вашим объемом данных можно не беспокоиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2007, 21:48 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
MBG , чё-то какое-то малопонятное словоблудие наблюдается, сначала MBGPostgreSQL после каждого коммита НЕ СБРАСЫВАЕТ данные на диск, а держит их в буфере.а потом уже MBGПро сброс WAL буфера слышали, а вот куда он сбрасывается - не понимаете. А сбрасывается он в журнал транзакций.Так сбрасываются данные на диск при коммите или не сбрасываются? Или у вас таки журнал транзакций на RAM-диске находится, для повышения такскть надёжности и отказоустойчивости? Но вообще, кнэшна, интересно бы найти ответ и на исходный вопрос. Может дело в том, что данные на диск попросту не сбрасываются, а зависают где-то в буфере диска? Или связка Delphi -> Zeos -> PG 8.2.3 даёт такие чудовищные накладные расходы, что разницы между commit'ом по одной записи или по 1000 записей нету? Для исключения первого варианта есть волшебная кнопка Reset, для исключения второго можно попытаться запустить запросы напрямую, через консоль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 12:00 |
|
||
|
Как транзакции влияют на производительность?
|
|||
|---|---|---|---|
|
#18+
Sad Spirit MBG , чё-то какое-то малопонятное словоблудие наблюдается RTFM ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2007, 12:53 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34638007&tid=2005306]: |
0ms |
get settings: |
13ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
80ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 258ms |
| total: | 443ms |

| 0 / 0 |
