Плохо спроектированная система CRM / CMS / SCM / Call Center, разработанная с использованием C # / ASP.NET / MS SQL Server.
Проблема, с которой я сталкиваюсь, заключается в том, что клиент использует эту систему в производстве и приближается к очень загруженному периоду. Бизнес является полусезонным, и это означает, что критически важно, чтобы система работала в это время. Все вышеупомянутое запускается из одной основной базы данных с использованием SQL-сервера, и из-за чрезмерно сложных / больших SQL-операторов сервер базы данных требует большой нагрузки.
Сам сервер впечатляет 16 ГБ ОЗУ и 16-ядерной вычислительной мощностью. На данный момент с этим еле справляется. Так что в напряженный период он упадет. В принципе нет времени программно исправлять проблему. Нам нужно отказаться от оборудования, чтобы решить проблему.
Это подводит меня к моему вопросу: для реализации балансировки нагрузки SQL мне нужно выполнить некоторую работу по разработке или есть способ балансировки нагрузки без разработки? Интернет-провайдер, на котором размещен сервер, сообщил, что нам необходимо провести некоторую разработку.
Самым большим узким местом в системе произвольной базы данных всегда является дисковый ввод-вывод *.
16 ядер? пффф. У вас тоже 16 дисков работает в raid-10?
Если нет, возьмите их.
-
* Конечно, вы не показываете абсолютно никаких показателей производительности, поэтому, если вам интересно узнать, какие советы мы можем вам дать, начните собирать данные о производительности и показывать их.
Фактически, пока вы этого не сделаете, вы не сможете доказать наличие проблемы.
Не существует такой вещи, как постоянное хранилище с балансировкой нагрузки. Вы можете разделить хранилище (сегментирование), которое работает только для очень узких конкретных проблемных областей или для приложений, явно разработанных для горизонтального масштабирования с самого начала, вы можете масштабировать чтение с помощью читаемого режима ожидания (репликация, доставка журналов, зеркалирование + моментальные снимки, AlwaysOn), который работает для отчетов с приемлемой задержкой обратного отсчета, и есть даже из сложных схем репликации мастер-мастер, которые не работают.
Так что ваши только вариант - исправить приложение или расширить базу данных. Исправление приложения всегда дает наилучшие результаты, но требует доступа к очень редким ресурсам (хорошие разработчики) и времени. Другой альтернативой, которая никогда не будет соответствовать результату исправления приложения, является увеличение базы данных. Что требует от вас определения узкого места. Ожидания и очереди это отличная методология, которая доказала свою эффективность при правильном применении. ЕСЛИ вы не знаете, как это сделать, свяжитесь с уважаемый профессионал и попросите о помощи.