Добрый день! Скажите пожалуйста ускорит ли работу баз 1С так называемый гипервизор или нет его смысла ставить? Есть сервер на linux и установленный postgresql, на котором крутятся базы 1С.

А причем здесь гипервизор и 1С?

гипервизор - средство управления ВМ, монитор ВМ, если хотите

(1) поэтому и спрашиваю, так как на сервер хотят установить гипервизор.

(0) Ты хотел сказать замедлит?

(0) А с чего он должен ускорить её работу? Замедлить - запросто...

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

(6) ранее не работал с гипервизорами

(6) "назвав приличную сумму за это все".
Ну так включите в договор гарантии ускорения. Хотя бы на год. Будете их в моск иметь по любому случаю замедления.

(7) изучи http://www.gilev.ru/virt1c/

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

+(8) Проблемы со скоростью это не решит. Но в зато вморальном плане ...

(10) Есть некоторые операции в 1С которые при достаточном кол-ве оперативки в виртуалке как это ни странно ускоряются.
На фоне общего торможения.

(12)+ Это особенно заметно на hdd и почти не заметно на ssd кста.
Виртуалка/гипервизор типа vmware он зараза такая кэширует обращения к дискам если ram много.

(13)+ Выглядит это как повторное выполнение того же отчета на не изменившихся данных занимает ничтожно малое время.

(12) Некоторые - это выход из программы? ))

(13) Что такого кэширует гипервизор, чего не кэширует ОС?

(16) все запросы к ssd но тут ньюансов много.
(0) Не верь, ресурсов уберет и замедлит наоборот.

(17) Вот нюансы и интересны. Есть они у тебя?

А балабольства не люблю.

(17) Некоторое гипервизоры как было сказано ранее кешируют запись на любой внешний носитель в оперативке. Если скорость ssd намного меньше чем скорость памяти и кеш большого объема то прирост скорости может составлять существенную разницу даже на глаз при некоторых операциях с БД, особенно если под кеш выделена опустим значительная часть размера БД.

Че тут балабольствовать если и так всё ясно как пень?

А вообще: http://www.gilev.ru/virtual/

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

Конкретика есть? Личный опыт, ссылки на описание чужого опыта? Пока это все балабольство.
Garykom вообще говорил о чтении.

(21) Конкретика есть но я специально её вот не хранил до сего момента. У клиента был и есть гипервизор на лине + для дискового кеша выделено около 16 Гб ОЗУ. Без него было тоскливо, с ним быстрее чем нативно. Замерял на глаз но в течении суток там и там.
Сугубо из личного.

А с чего вы взяли, что не ускорит? Ключевые слова "назвав приличную сумму за это все".
Может они заменят Celeron какой-нибудь, на Xeon, тогда все ускорится не смотря на тормоза виртуализации. Автор начальные и конечные условия не обозначил.

У кэширования в виртуальной машине, при работе в ней PostgreSQL, есть существенный недостаток - "включенный кеш системы виртуализации эквивалентен fsync=off и full_page_writes=off", отсюда https://www.sql.ru/forum/1058995/missing-chunk-number-0-for-toast-value-xxx-in-pg-toast-yyy , что значительно повышает риск повреждения баз данных.

(0) Просто админы страшно любят виртуализацию. А деньги так вообще все любят.

(21) "СУБД, если пишет в обход кэша ОС" не может обойти кэш гипервизора.
И даже если кэш субд неправильно настроен или нет его то гипервизор дает свой.

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

Короче виртуалки это зло в плане ухудшения быстродействия.

Но это повышение удобства, надежности, гибкости и можно в некоторых случаях "неправильных" субд и 1С в неких моментах ускорить.
Хотя один хрен будет в целом сильно хуже чем "правильные" субд и 1С на физическом.

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

(25) я не одмин, но было время когда отвечал за инфраструктуру компании. И когда все железки (т.наз. "сервера") были "уникальны", т.е. все крутилось на них так, что если что-то наикнется, то сценарий - брать бэкапы и плясать вокруг этого колхоза с бубном неизвестное количество времени, потому что на остальное "денег нет, но вы держитесь". Да, были развернуты в резерве скуль и 1С, АД и пр., но все это колхоз. Особенно когда работа круглосуточная и твоя жпо на кону. Поэтому все должно быть завиртуалено до такой степени, чтобы выключив любую железку из розетки, ни бизнес, ни пользователи даже не должны чухнуть о том, что что-то случилось. Поэтому админы, которые страшно любят виртуализацию, правильные админы.

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

(25) и правильно делают....

(21) "Современные ОС без гипервизора точно так же "кешируют запись на любой внешний носитель". "
Только если приложение открывает файл в соответствующем режиме. По умолчанию да. Но есть еще флажки O_SYNC и O_DIRECT. И многие СУБД любят такое, оставляя за собой полный контроль над записью данных и кэшированием. Иногда это бывает чрезмерно.

Так, например, в 1сv7 при сравнении и объединении конфигураций используется синхронная работа с диском, а также в синхронном режиме пишут свои временные данные так называемые "черные запросы". Именно поэтому так сильно ускоряется работа семерки при размещении каталога временных файлов на рамдиске. В этом случае безусловно включенное кэширование было бы полезным.

(27) Вот это взвешенный взгляд, согласен.

(0) Я подозреваю, что виртуализация предложена непосредственно в ключе баз postgresql. Когда каждая база поднимается в отдельном кластере postgresql (одна база - один кластер) на отдельной виртуалке - это очень удобно. Во-первых, параметры постгреса можно затюнить на профиль использования и специфику конкретной базы. Во-вторых, удобно бэкапить (специфика постгреса). В-третьих - удобнее мониторить.
Т.е. в принципе, для большого количества нагруженных баз на постгресе, виртуализация - стандартная практика.
Но надеяться что виртуализация решит существующие проблемы производительности - довольно смело. Скорее всего не решит.