Если бы вас спросили, может ли система поддерживать двойной рост, что бы вы ответили на три вопроса?

Question

Допустим, на вашей работе ваш начальник говорит:

  

Та система, которая утратила все институциональные знания, но, кажется, сейчас работает довольно хорошо, можем ли мы сбросить вдвое больше данных и выжить?

Вы совершенно не знакомы с системой.

Это в SQL Server 2000 (прежде всего, приложение базы данных).

Там нет тестовой среды.

Возможно, вы сможете захватить его по выходным, если вам понадобится выполнить тест.

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

Чтобы ответить на ответ от doofledorfer, ваши предположения почти на 180 градусов ниже. Но это моя вина за неоднозначный вопрос.

<Ол>

Один из главных серверов работает 7x24 на 70% -ной базе, и оттуда пики, и никто не знает, что он делает.

Это не проблема скупки или нытья ... У нашей компании может не быть большого выбора в этом вопросе.

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

Я надеялся, что кто-то скажет что-то вроде: посмотрите, отключите ли вы систему в воскресенье ночью в полночь и запустите тесты SQLIO, чтобы увидеть, насколько близка подсистема хранения к насыщению. Такие вещи.

Answer 1

<Ол>

Настройте тестовую среду, даже если мне придется сделать это на моем ноутбуке.

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

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

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

Answer 2

Вы только что описали типичный Agile-проект. Ваш ответ должен быть:

<Ол>

Я не знаю, и я не смогу сказать без тестирования.

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

Итак, давайте проработаем базовый список факторов риска и способы их устранения.

Как только мы это сделаем, давайте проработаем их в обратном порядке риска; и принять решение об остановке / продолжении по мере развития результатов.

и др.

Без участия руководства и участия, по крайней мере, на этом уровне, любой другой ответ, который вы можете дать, - это желание с высокой степенью риска и "3 наиболее важные". это не Sequitur.

Я был бы оптимистичен, если ваша текущая система уже не загружена. Большинство серверов должны работать с емкостью менее 50% на всех ресурсах, или же они должны быть в состоянии жизнеобеспечения. И я ожидаю, что вы не будете вести разговор, если существующий сервер уже будет иметь дело с проблемами загрузки; хотя "кажется, сейчас работает довольно хорошо" достаточно неточно, чтобы быть тревожным.

Answer 3

это в основном зависит от текущего уровня. Если удвоение идет от 2 ГБ до 4 ГБ, просто сделайте это. Если это будет от 1 ТБ до 2 ТБ, у вас есть кое-какие планы.

Я собираю некоторую информацию с помощью Performance Monitor и предоставляю ее, чтобы помочь принять обоснованное решение.

Answer 4

Это зависит от того, что вы подразумеваете под "удвоением данных".

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

Проблема возникнет, если вы удвоите объем данных во всех таблицах, так как тогда время выполнения может возрастать экспоненциально и это может привести к серьезным проблемам.

Но в целом я бы поддержал ответ от doofledorfer