Да нет, почемку NDA :)
Просто серверов железных несколько, виртуалки бывают перемещаются между ними, кроме продуктива фреша там еще много чего крутится. Не очень показательно будет )
Вот цифры в 8 ядер 3.5ГГц и 40 Гб RAM показательны, диски на SSD, раньше были на Windows Storage (Tiered Pool). Если бы у нас не было роботов, думаю в два раза можно ресурсов урезать.
Нагрузка самая большая конечно на серверах приложений, им ресурсов выделено значительно больше.
350 Гб не космическая цифра конечно, но повыше среднего )
Мы постоянно экспериментируем с количеством серверов и ресурсами, на данный момент у нас 2 основных СУБД под конфигурации БП, один СУБД под служебные ИБ (агент сервиса, менеджер сервиса), еще 2 под небольшие базы, такие как УНФ, ЗУП.
Серверов приложений 5 экземпляров, 2 из которых сильно нагружены.
Пользователей у нас не много, в районе 100.
Работает это все в виртуальных машинах, в качестве гипервизора Hyper-V. Железные процессоры Xeon E5-2637 v2. NUMA включено, но с ресурсами поступаем аккуратно, не допускаем заметной конкуренции.
Машинам с СУБД выделяется 8 ядер/40 Гб RAM. Но с кластерами и настройками, описанными в статье основное потребление приходится на ночные регламентные задания и роботов.
В целом я могу сказать, что СУБД далеко не самые ресурсопотребляющие машины.
Машины виртуальные, на Hyper-V.
В среднем это от 4-6 ядер/10 Гб RAM на сервер приложений и от 4 ядер/20 Гб на СУБД… Внимательно следим за производительностью дисковой системы.
Сервер приложений на linux мы использовали где то полгода, коннектиться через COM на него можно без проблем, работает стабильно, но по совокупности факторов нам удобнее держать его на Windows.
Всё так, экономия не последняя из причин выбора этой СУБД, а ещё мы любим open source :)
Сравнительное тестирование мы проводили в ограниченном объёме и поняли, что производительность PostgreSQL при правильной настройке не хуже в наших условиях эксплуатации. Специалисты 1С солидарны с нами.
Резервное копирование начиналось с банального pg_dump раз в сутки, а сейчас оно реализуется через непрерывное архивирование WAL.
В случае форс-мажора мы можем откатиться на конкретный момент времени (point-in-time restore).
Более подробно о своем опыте использования PostgreSQL, практиках и ошибках мы планируем написать отдельную статью.
Просто серверов железных несколько, виртуалки бывают перемещаются между ними, кроме продуктива фреша там еще много чего крутится. Не очень показательно будет )
Вот цифры в 8 ядер 3.5ГГц и 40 Гб RAM показательны, диски на SSD, раньше были на Windows Storage (Tiered Pool). Если бы у нас не было роботов, думаю в два раза можно ресурсов урезать.
Нагрузка самая большая конечно на серверах приложений, им ресурсов выделено значительно больше.
350 Гб не космическая цифра конечно, но повыше среднего )
Мы постоянно экспериментируем с количеством серверов и ресурсами, на данный момент у нас 2 основных СУБД под конфигурации БП, один СУБД под служебные ИБ (агент сервиса, менеджер сервиса), еще 2 под небольшие базы, такие как УНФ, ЗУП.
Серверов приложений 5 экземпляров, 2 из которых сильно нагружены.
Пользователей у нас не много, в районе 100.
Машинам с СУБД выделяется 8 ядер/40 Гб RAM. Но с кластерами и настройками, описанными в статье основное потребление приходится на ночные регламентные задания и роботов.
В целом я могу сказать, что СУБД далеко не самые ресурсопотребляющие машины.
В среднем это от 4-6 ядер/10 Гб RAM на сервер приложений и от 4 ядер/20 Гб на СУБД… Внимательно следим за производительностью дисковой системы.
Сервер приложений на linux мы использовали где то полгода, коннектиться через COM на него можно без проблем, работает стабильно, но по совокупности факторов нам удобнее держать его на Windows.
Сервер СУБД — Debian 7 из-за зависимостей в дистрибутиве PostgreSQL от 1С.
Машины крутятся на наших мощностях.
Сравнительное тестирование мы проводили в ограниченном объёме и поняли, что производительность PostgreSQL при правильной настройке не хуже в наших условиях эксплуатации. Специалисты 1С солидарны с нами.
Резервное копирование начиналось с банального pg_dump раз в сутки, а сейчас оно реализуется через непрерывное архивирование WAL.
В случае форс-мажора мы можем откатиться на конкретный момент времени (point-in-time restore).
Более подробно о своем опыте использования PostgreSQL, практиках и ошибках мы планируем написать отдельную статью.