и то и другое виртуалки. Лежат правда на разных хостах. Кол-ва оперативки и проца идентичные. Диски на которых лежат виртуалки - разные.

а на момент тестирования общая загруженность гипервизора одинаково? IO, проц?

Лин машина вообще на не загруженном хосте. Вин машина на загруженном

archive level WAL + копирование WAL в сторону на тот же диск?

Это почти x3 по записи

archive level WAL + копирование WAL в сторону на тот же диск?

Нет, это все на сетевой ресурс уходит

Т.е. с большими задержками?

Т.е. с большими задержками?

величину задержки не знаю. гигабитка до сетевого хранилища

конечно там еще запись не только от меня идет.

Поставил minimal и archive_command = off. Улучшилось, но не на много + 30 единиц дало.

Не люблювиртуализацию

+100500

вин машина тоже под виртуализацией и на дефолтном конфиге

выдает больше попугаев

не могу понять в чем засада:)

не могу понять в чем засада:)

Вангую, в компонентах интеграции гипервизора

А еще там флаги всякие у CPU есть, настройки энергосбережения

ну /proc/cpuinfo показывает что проц использует максимум частоты.

да и нагрузки на процессор нет как таковой.

А еще там флаги всякие у CPU есть, настройки энергосбережения

Ну если углубляться - то можно сослаться на привязку процессов к ядрам и тп.

Может дело в файловом кэше на ОС? Надо длительный тест запустить с большим объемом данных - чтобы невилировать разные кэши

там может элементарно в винде стоят паравиртуальные IO драйверы а в линукс их ни кто не ставил и оно работает в режиме эмуляции, вот и разница...

В современных дистрибутивах вроде virtio и vmware paravirtual из коробки - прям в ядре

ну да. Его еще бы включали при создании виртуалки...

а то установщик не увидел диски и сетевуху и тут прилетает: «да поменяй на legacy и все увидит»....

в RH* по дефолту вроде только virtio и есть

ни для vmware ни для HyperV в дистре ни чего нету.

диски vmware есть. Нет из коробки управления (для чего ставится vmware tools или gпакет open-vm-tools).

Про HyperV не скажу - не работал

Паравиртуализация vmware как раз с виндой старше 2008 не дружит.

Давно винду не ставил - но еще год назад небыло драйверов на vmware paravirtual на 2012 винду... и она как раз - не видела диски.

а virtio в ней я отродясь не видел из коробки. Всегда отдельно приходилось ставить после установки на legacy

а virtio в ней я отродясь не видел из коробки. Всегда отдельно приходилось ставить после установки на legacy

Можно же прямо во время установки драйвера подкидывать

Ушли от темы. Пробовали длительный тест? Думаю системы начнут сравниваться по попугаям

странно, ставил винду в QEMU/KVM и не ззамечал проблем

странно, ставил винду в QEMU/KVM и не ззамечал проблем

а там и нет проблемы. проблема в низких попугаях на centos

точнее в разнице в попугаях. Причем значительноей

хм, по сравнению с чем?

странно, ставил винду в QEMU/KVM и не ззамечал проблем

Тип диска указывали virtio?

нет, IDE

точнее в разнице в попугаях. Причем значительноей

Длительный тест нужен

нет, IDE

Ну в IDE вы очень теряете в скорости диска

Добрый день. Имеются две машины, windows + postgres 9.4.9 сборка 1с от postgrespro и centos 7.2 + postgres 9.4.9 сборка 1с от postgrespro + checksums + пишутся wals в архив. Win машина с у становленным по дефолту конфигом (128 мб shared_buffers, 4mb work mem, 64mb maintenance_mem). Centos с конфигом с pgtune - 2gb shared_buffers, 20971kB work mem, 512 maintenance_mem). Запускаю аналогичную pgbench на обеих машинах. На винде tps выше в 2-3 раза. На Centos 159, на win - 530. С чем это может быть связанно? Не пойму почему на голом конфиге производительность в попугаях выше?

с virtio как-то не сложилось

хм, да это интересно

интересно, а на centos 6.6 такая же трабла?

и как FS в центоси устроена?

может у вас несколько слоев...

lvm + xfs. но

это явно не 3 раза:)

Ну курочка по зернышку клюет

lvm + checksum + wal

это уже притягивание за ушил:)

валы я отключил.

разница в 30 единиц

Чексуммы?

их естественно не отключал. Но повторюсь, это не в три раза. Читал статью, где приводились тесты, чексуммы на 10 процентов садят производительность.

хм, а диски какие?

SAS 15000rpm?

ну или SSD?

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

про диски ничего сказать не могу. Не я ими занимаюсь. Но явно затык не в них должен быть. При pgbench они не сильно нагружаются на запись и чтение

попробуйте на centos прогнать mamonsu tune под рутом :) и перезагрузить

по сравнению с ванильным pg, тест на запись в течении 2 часов показывает результат x10

def _configure_virt_guest(self): if not self.sys_info.is_virt_guest(): return self._run_query( "alter system set synchronous_commit to off;")

ERROR: S client not available

норм тюнер!

is_virt_guest

ты веришь в то что у тебя тебя там реальный fsync?

ню-ню

def _configure_virt_guest(self): if not self.sys_info.is_virt_guest(): return self._run_query( "alter system set synchronous_commit to off;")

https://momjian.us/main/writings/pgsql/virtualization.pdf

я апеллирую к логике и к enterprisedb :) а вы к чему? @netneladno

я как всегда мимо проходил, но к логике лучше апеллировать развернутыми предлоожениями, а не ссылками и вызовами на дуэль

а в другой презентации пишут что WAL sync does go to the underlying disk on VMware ESX.

на форуме вмваре The fsync command will be handled by the guest OS - the ESXi server virtualize the resources used by the VM including disk so when the VM issues a write the ESXi takes that write and performs it within the VMDK or RDM - the guest insures the wirte is done the same way it is done in the pphysical world

ок, можно доверять производителю виртуализации, на слово :)

речь то не про fsync

ну с твоей логикой можно и fsync = off поставить

хуле

его никто не отключает

хуюле

читаем что такое syncronous_commit

и сопоставляем его с тем как гарантированн доступ к CPU

при виртуализации

при sync_commit = off в специальной области шаренной памяти выделяется буффер

который либо таймауту или переполнению сбрасывается с fsync

теперь смотрим на виртуалку и думаем, когда процессу, запущенному в виртуальной системе гарантируется доступ к CPU

попробуйте на centos прогнать mamonsu tune под рутом :) и перезагрузить

погоняю. Ему можно ограничения указывать по поводу максимального юза опертивки?

теперь смотрим на виртуалку и думаем, когда процессу, запущенному в виртуальной системе гарантируется доступ к CPU

он и не на виртуалке не гарантируется :)

без -rt, но постгрес по идее под -rt не точили

мы гоняли тесты на -rt :) for fun, с кластером на pacemaker

на особо загруженных системах хербит не отсылает потому что никто не гарантирует доступа

и ноду из кластера выбивало

о да

есть у осма в кластере такой сервер, http://munin.openstreetmap.org/openstreetmap/vial.openstreetmap/index.html - на пиках в io замирает

не ну что замирает - понятно, и без кластера :) вопрос в том, что машинку с работающим pg дергают по питанию, из-за шедулера

а nice -20 хертбиту - не хватает?