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

Даниил16 Гб ОЗУ Занятая память: 5-8ГбМало. Ради дискового кеша нужно больше.

Даниил / БД на быстром SSD / Ширпотребный SSD не для сервера. Enterprise SSD (SLC/MLC) имеют большую цену, а ширпотребные TLC/MLC- мусор с заранее неизвестным качеством и сроком жизни. Особенно, с OLTP нагрузкой. К тому же, один ширпотребный SSD плохо держит параллельную нагрузку. Лучше аппаратная плата RAID1 на 2 HDD или RAID10 на 4. Тогда будет до 4 потоков на чтение и до двух на запись. Винчестеры лучше выбирать классом повыше.

ДаниилWin7Если настроить и поотключать всё лишнее, то это лучше ненужного сервера. При таких объёмах серверная операционная система- лишняя трата денег на ненужный функционал.

ДаниилНагрузка на HDD и LAN - минимальная: HDD в пике 20 МБ/с, обычно 0-4 МБ/с; LAN в пике 40 МБит/с, обычно 2-10 МБит/с.Сетевую карту лучше поставить отдельную, встроенный Realtek слабоват. Он имеет б О льшие буфера для входящего трафика- нужно наоборот. На отдельной сетевой карте увеличить исходящие буфера до максимума.

ДаниилВ итоге видимое узкое место - это процессор.Так всегда кажется, но чаще всего узким местом является программный стек.

ДаниилПри пиковой нагрузке, когда около 60-80 операторов создают новые заявки (1 заявка - это INSERT по 20-100 записей в 5-10 таблиц огромного размера + привязанная в этому бизнес-логика на 15-20 триггеров и около 20-30 ХП, меняющих еще 10-15 таблиц) и эта заявка сохраняется (в толстом клиенте, но вся бизнес-логика выполняется на стороне сервера) до 5-7 секунд. Это много. Считаю нормой - максимум 2 секунды.Количество залогиненных пользователей не так важно. Нужно смотреть на количество одновременно выполняющихся запросов за одну секунду. Оно не должно быть существенно больше количества ядер процессора. Пики возможны, но не должны быть длительными.

ДаниилКроме этого у пользователей есть достаточно сложные отчеты, которые могут формироваться до 1-2 минут.Нельзя ли настроить репликацию или что-то подобное на отдельный компьютер? OLTP и отчётная (или OLAP) нагрузки плохо совместимы, начиная с определённого уровня. Отчёты можно держать на readonly базе, если софт умеет- иногда это улучшает производительность.

ДаниилПоскольку процессор на обычном бытовом компьютере апгредить уже нет смысла, то пора переходить на серверное железоСмысл зависит от многого. Если дадут денег, то можно. Однако, серверное железо и софт будут существенно дороже. Нужно много вложить, чтобы получить сходную производительность. Серверное железо не для производительности, а для большего количества обслуживаемых клиентов и "гарантированной" безотказности.


Даниил (не исключая оптимизации DDL и запросов).В первую очередь. Может, не понадобится сервер.

Даниил1) Даст ли ощутимый прирост производительности переход на процессоры Xeon Gen9 или Gen10 Silver c 16 ядрами но частотой 2.1-2.4ГГц (вместо i7 8 ядер 3.4ГГц) или же требуется увеличить кол-во ядер при сохранении примерно той же частоты что у i7 3-4 ГГц?Смотрите на число одновременно выполняющихся запросов.

Плюсы серверного процессора: ядер больше, кеш больше. Минусы: частота либо существенно меньше, либо несущественно, но с огромным ценником и кондиционированная серверная нужна- шумит и греется. Обычно, для серверов и память медленная, но чуть надёжнее.
Если в базе много алгоритмической работы, то может требоваться большая частота. Мощные десктопные процессоры в некоторых случаях лучше:

Если одновременных запросов меньше, то предпочтительнее частота:
i7-7700k
i7-7740x

Если одновременных запросов больше, то предпочтительнее греющиеся ядра и L2 кеш:
i7-7820x
i7-9800x

Dimitry SibiryakovWinDbg, Process Explorer.

Видимо, Process Monitor , т.к. нужно в динамике?

Ivan_PisarevskyНа механических винчестерах оно будет тупить настолько безбожно, что можно даже не начинать. HDD это опечатка?Зависит от нагрузки. Если отдаётся много мелких непоследовательных наборов данных, то RAID 10/4 HDD не будет быстрее. Если отдаются большие последовательные данные, то 4 медленных потока могут стать лучше одного быстрого. Запись тоже имеет свои особенности. Не учитывая этого можно вынести бюджет TBW за месяц.

Но держать OLTP базу на SSD- это либо нонсенс, либо предмет гордости администратора, что у него все процессы не хуже Tier 3 и есть горячий резерв с гарантированным простоем не больше минут.

ДаниилЕсть смысл стремится к тому, чтобы весь объем БД влезал в ОЗУ?Не уверен, что используемая версия СУБД имеет собственное полноценное кеширование, как ведёт себя ОС- отдельный вопрос. Всегда существуют части, котором обязательно нужно сбросится на диск. И размер данных не всегда позволяет.

ДаниилКак это посмотреть? Посчитать по MON$TRANSACTIONS? Но там только активные будут.Что-то подобное fbprofiler , вероятно, будет полезным.

ДаниилТ.е. для 100-150 клиентов покупать серверный xeon на более десятка ядер при нормально спроектированной и оптимизированной БД не имеет смысла?Если количество одновременных запросов превышает в полтора раза количество ядер под СУБД более 2-3% рабочего времени или это происходит подряд или попадает на какое-нибудь закрытие смены, то проблему придётся решать. Сервер на нескольких W-3175X - это самое дешёвое решение в смысле усилий программиста.

Например, если при открытии документа на редактирование тянется куча редкоизменяемых справочников и эти справочники обновляются не их основными потребителями, то их можно положить на отдельный компьютер под репликацией. Пусть приложение ходит на 2 сервера. Или кешировать в локальный, например, sqlite. Тем более, что софт самописный.

ДаниилRAID5Лучше не стоит. Зеркала или RAID 10 вполне достаточно.
ДаниилЛучше по вашему выбрать вариант RAID на SSD?И будут они жить долго и счастливо, пока не умрут в один день или раньше, от кривизны в прошивке. Или придётся следить за графиком ротации, следить за деградацией и подтягивать процессы к Tier 3.