Виртуализация postgresql на KVM.

Какое ядро? Ос? Железо? Может, имеет смысл сменить ядро? Или вручную создать kvm контейнер, или на libvirt, чтобы посмотреть узкое место? Поискать средства мониторинга и трейса kvm? В конце концов есть Xen, Docker на крайняк. Но, думается, KVM не хуже.

База > 300 GB

А где она физически лежит и как вм к ней доступается?

привет. вопрос такой, какая high-level цель такого упражнения? ты собрался что-то еще держать на этой машине, или для унификации менеджмента, или для

буквально сегодня обсуждал это с нашими инженерами MySQL и kernel так как есть желание использовать стандартные средства менеджмента контейнеров, так вот, вариантов кроме как прямого доступа к блочным устройствам с IOMMU нет. в таком сетапе потери в раене 0.5%, что при нашем масштабе слишком дорого увы но большинству людей вполне подходит. попробуй.

Centos 6.5 с родным ядром. На нём крутилась физическая машина. После установки Proxmox'a на эту машину в качестве гостевой ОС был поставлен тот же Centos.

Проц: Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz

Мать:

Manufacturer: Intel Corporation

Product Name: S2600CP

Version: E99552-510

Памяти 128 гигов.

Я тоже считаю, что KVM не хуже, но вот был опыт внедрения только нескольких нересурсозатратных ВМ, которые сейчас чувствуют себя вполне отлично.

База лежит на 10 рейде из 8 SSD дисков на этой же машине. Пробрасывал в ВМ virtio-драйвером. Проверял скорость записи\чтения - думал может затык в этом - около 400мб\с.

Да, хотели докрутить на него виртуалок. В пиковые моменты загрузка процессора на сервере доходила едва до 40%. Немного отрезали бы памяти у postgres'a и докрутили еще пару машин на него же.

Ну так оставьте базу на хосте + к ней виртуалки

база все время тормозит или в пиках нагрузки? если в пиках, то надо смотреть на kvm_stat в нормальном виде и в пике, если постоянно, то просто kvm_stat

проксмокс работает на дебиане, там kvm часто глючит, причем даже на альфе федоры таких глюков не наблюдается. если хост всего лишь один, то я бы просто поставил центос хостовой ОС - он стабильнее и проверен,в отличии от дебиана.

памяти, как я понимаю, достаточно, но: (a) как она распределена по numa nodes относительно хостовых CPU? и (б) как настроены процессоры VM?

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

зы у меня есть база примерно такого же размера на mssql над kvm, и тормоза бывают в пиковой нагрузке, потому что диски не ssd, к сожалению. в остальном все пашет отлично.

проксмокс работает на дебиане, там kvm часто глючит

Проксмокс использует ядро 6 rhel'а. Планируют переходить на 7, так что kvm там такой же.

Проксмокс использует ядро 6 rhel'а. Планируют переходить на 7, так что kvm там такой же.

честно говоря этот салат напрягает еще больше. ядро от RHEL, юзерспейс от дебиан, хз что и как и где прикручено и где что от какого дистра. kvm это не только модуль но и целый стек вокруг, на одном модуле VM не поднимешь

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

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

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

в посте речь шла про постгри на 300+ гигов. не думаю, что ТС собрался запускать ее под масдаем или солярой.

хей-хоу. привет от воскресших из мертвых) извиняюсь за бестактную пропажу посреди разговора.

есть к тебе несколько вопросов, т.к. ты являешься для меня авторитетным лицом, особенно в вопросах о rhel\kvm, но не знаю, увидишь ли ты это сообщение, поэтому будем считать его эхо-реквестом)

будем считать что я отозвался в пределах таймаута :)

даже быстрее, чем я думал :)

в общем, не было возможности рулить виртуализацией на этом сервере - он является неким жалким подобием «продакшена» для этой конторы)) да и начальство после той «попытки» добро не давало)

сейчас собираемся подойти к этом более обдуманно и попробовать еще раз. почему-то именно KVM меня прельщает больше всего и хочется все-таки разобраться с ним. мне кажется, что именно за ним ближайшее будущее виртуализации и именно поэтому я не хочу оставить работать БД на хост системе и прикрутить виртуалки сверху - хочется понять и разобраться. копнуть KVM поглубже) поэтому вариант с БД на хосте оставим на случай «все очень плохо».

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

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

теперь ближе к делу:

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

2) на постгре крутится 1С база. жалоба была от 1Сника: какая-то там его «обработка» за ночь выполнила всего один день (а на голом железе за ночь неделя проходила). и, как мне кажется, я не смогу у него выведать подробности этой «обработки», т.к. он, кхм, немного туповат) а я пока в БД так не шарю, чтобы ответить на этот вопрос :( но в этот раз попытаюсь узнать побольше

3) про kvm_stat учту. не знал про него

4) numa-нода на сервере одна ибо и процессор один единственный. или я что-то не так понимаю? и что подразумевается в вопросе «как настроены процессоры в VM?»

5) и наконец. какие бы советы и\или рекомендации вы могли дать по настройке KVM для следующей попытки?) у меня это был первый опыт внедрения виртуализации для довольно-таки нагруженной системы и, к сожалению, довольно-таки неудачный)

пункт на самом деле всего один - пятый. Но начнем с начала.

Во первых, для очень серьезных нагрузок, особенно БД, нет ничего лучше настоящего железа. Как не крутись, а ж**а сзади, как говорится.

Под KVM можно оптимизировать многие параметры. Все зависит от конкретной нагрузки и потенциальных узких мест. И тут уже я заранее подсказать вряд ли что либо смогу без дополнительной информации.

Обычно базы это диск и процессоры. Оптимизировать доступ к дискам можно устранив прослойку между собственно блоками диска, и qemu, так что самое быстрое это прямой доступ к диску или LV, и формат raw. Сверху надо выбрать драйвер, virtio_blk или virtio_scsi - опять же, при разных нагрузках они ведут себя по разному, надо гонять максимально приближенные к продакшену тесты на каждом из вариантов. На хосте и в ВМ есть io scheduler, надо посмотреть комбинацию которая максимально ускорит обработку IO. обычно это deadline/noop, но бывает по разному.

С процессорами, основной принцип - максимально приблизить настройку виртуальных процессоров к реальным. То есть, если есть NUMA, то или цеплять все виртуальные процы к одной ноде, или цеплять к разным, с четко заданными лимитами памяти, иначе появится оверхед при переключениях контекста. Короче если хочется выжать из системы все до последнего процентика, надо шить костюмчик по клиенту, а не по универсальному размеру

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

я хочу понять, научиться и разобраться. не по всему мне, конечно, хватает знаний, особенно по самим БД, но я стараюсь активно навёрстывать :)

Под LV подразумевается logical volume? Или я что-то не так понимаю? И как организовывается прямой доступ к диску? Я пробрасывал диск (в хосте это аппаратный реид) в проксмокс добавлением строки в конфиг файл virtio0: /dev/sdc. Замерял скорость записи - около 400 мб\с было вроде. IO-scheduler для этого диска и в хосте, и в госте был выставлен в none, т.к. рейд на SSD.

NUMA не имеется :)

А я думал, что память для БД даже поважнее проца... Он же, как-никак, кешит данные с диска, а с опертивой он общается ведь гораздо быстрее, чем с диском :)

Если есть еще что-нибудь, то я, на правах чайника, с удовольствием выслушаю и намотаю на ус :)

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html...

если про диск - вот это, то я, получается, по сути то же самое ведь и делал. только немного по-другому :)

ну да, LV как том из LVM. Пробрасывается, а точнее просто подключается просто записью в domxml, это описание настроек VM в XML формате. qemu без разницы где лежит блочное устройство, главное - дать доступный путь к нему в строке <source dev='/dev/mapper/...'/>

proxmox, а что такое старье?

с большими объемами незнаю как, но свежее qemu он же kvm работает прекрасно без учта слона, думаю с ним тоже будет нормально

Почитай чем kvm отличается от гипервизоров типа vmware на уровне доступа к файловым объектам.

Слон сам по себе безобиден и шустр, но смотря какие оптимизации на вставку, чтение, обновление, объем. Опять же настройки fsync.

толи я дурак, толи лыжи не едут. я почти ничего не понял из того что вы сказали.

что значит proxmox старьё?

второй абзац похож на случайный набор слов

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

похож на второй абзац. ничего не понятно

(не могу разобрать, похоже на эльфийский)

ага, вкурил. вот пробую на тестом серваке сейчас.

    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source dev='/dev/mapper/virt-oceansrv_root'/>
      <target dev='vdc' bus='virtio'/>
    </disk>

Кэш ведь лучше writeback выбрать? Почему-то везде по дефолту none пишут) И еще видал параметр io=(native|none|что-то еще вроде).

Настройки процессора, как я понимаю, лучше доверить libvirt'у?)

cache=none, проксмокс-бяка

Почему-то везде по дефолту none пишут) И еще видал параметр io=(native|none|что-то еще вроде).

Вы бы или документацию читали и элементарные вопросы не задавали или писали сразу в джоб. Хорошо приготовленный KVM в некоторых случаях на том же железе может позволить работать системе в виртуалке быстрее чем на самом железе (причем том-же самом). p2v 1с+postrges на win такой эффект дает практически гарантированно.

Кэш ведь лучше writeback выбрать? Почему-то везде по дефолту none пишут) И еще видал параметр io=(native|none|что-то еще вроде).

только если там есть хороший UPS и контроллер рейд на батарейке. none - самое безопасное.

И еще видал параметр io=(native|none|что-то еще вроде).

ага, это управление обработкой io, обычно native или threads

Настройки процессора, как я понимаю, лучше доверить libvirt'у?)

ага, только надо убедиться что он скопировал в VM настройки процессора хоста

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

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

Пробуй xenserver, как раз новый 6.5 вышел

не, к XEN-у не лежит у меня душа поставил и снёс его

Душа?!

Ты инженер или поп?

Ну и чем все закончилось? :)

Сейчас тупо в пгбенче разница между контейнером и квм около 80%.