Итак - у нас есть внутренняя база данных компании, обычные вещи: управление клиентами, телефонными звонками, сделками по продаже и соглашениями / схемами с клиентами.
Это интерфейс Access 2000 и серверная часть SQL Server 2000 Standard. Один сервер, два процессора Xeon 3,2 ГГц, 2 ГБ ОЗУ, Windows Server 2003, загружает процессор примерно на 40% в течение всего дня, распределяя его по 4 ядрам, видимым для ОС (HT).
Внутренняя база данных плохо спроектирована и органически росла более 10 лет, поддерживаясь неопытными людьми. Он плохо нормализован, и некоторые из очевидных проблем включают таблицы с десятками тысяч строк без первичного ключа или индекса, которые также активно используются в соединениях нескольких таблиц для некоторых из наиболее часто используемых частей системы (например, приложение диспетчера вызовов, которое сидит на втором мониторе каждого по 8 часов в день и каждые несколько секунд выполняет большой неэффективный запрос).
Интерфейс не намного лучше, это типичный беспорядок из сотен форм, вложенных сохраненных запросов, плохо написанного встроенного SQL в коде VBA, десятков «причуд» и т. Д., И всякий раз, когда вносятся изменения, кажется, что что-то несвязанное ломается. Мы остановились на одном MDB, который работает «достаточно хорошо», и теперь у нас есть политика без изменений, поскольку у нас нет собственных тяжеловесов Access (и мы не планируем нанимать их).
В настоящее время компания медленно растет, увеличивается количество клиентов, звонков и т. Д., А также незначительно увеличивается количество одновременных пользователей, а производительность в последнее время заметно ухудшается (ожидание перехода между формами, ожидание заполнения списков и т. Д. )
Perfmon говорит:
Профилировщик SQL Server каждую минуту видит сотни тысяч запросов. Использование ЦП на клиентах практически равно нулю, что указывает на ожидание выполнения запросов на стороне сервера. Я пропустил эту рабочую нагрузку с помощью советника по настройке ядра БД, применил его предложения к тестовой резервной копии, но это не сильно изменило ситуацию.
Между прочим, у нас есть смесь 100 МБ и гигабитного Ethernet, все в одной подсети, 40 иш пользователей на двух этажах.
К вопросу.
На мой взгляд, у нас есть два варианта разрешения / улучшения этой ситуации.
Мы можем создать систему Intel i7 с сумасшедшими показателями производительности, на порядок меньших затрат, чем замена программного обеспечения.
Когда в конечном итоге будет разработана новая система, ее можно будет разместить в этом ящике, чтобы не было лишнего оборудования. Новая CRM-система то и дело откладывается, то откладывается, то откладывается - я не думаю, что это произойдет как минимум год.
Любые мысли по поводу этой ситуации, особенно если вы сами были здесь, были бы очень признательны.
Спасибо
Я собираюсь не согласиться со всеми здесь. Добавьте сюда какое-нибудь оборудование. Это дешево, быстро, легко и сэкономит вам время, необходимое для внедрения надлежащего решения CRM. Причина, по которой я защищаю то, что является анафемой практически для всех, не только на этой доске, но и на stackoverflow также, заключается в том, что я был менеджером / менеджером проекта и какое-то время занимался бизнесом (бизнес находится в кавычках из-за моей ненависти к этому слову). Судя по вашему описанию программного обеспечения, потребуется около года, чтобы перестроить что-то еще. Простое обнаружение / документирование бизнес-правил / причуд, вероятно, займет 2 месяца. Кроме того, разработка будет невероятно дорогой. Особенно по сравнению со стоимостью навороченного сервера.
На самом деле я собираюсь разместить набор веб-приложений для компании именно по этой причине. Внутренний ИТ-отдел не будет переводить его на лучшее оборудование, потому что они хотят перестроить его на новую платформу. Эта стоимость примерно в три раза больше, чем будет стоить его перевод на новое оборудование. Не говоря уже о том, что компания могла не продлить контракт через год.
Возможно, вам и не потребуется. Я предлагаю просто добавить несколько индексов / ключей в таблицу.
таблицы с десятками тысяч строк без первичного ключа или индекса, которые также активно используются в многотабличных соединениях
Прежде чем тратить много денег или времени, потратьте пару часов и добавьте индексы (или первичные ключи, если можете) к любым таблицам, участвующим в этих объединениях ... особенно для столбцов, используемых в предложении where. Вы можете легко повысить производительность в 10 раз всего за несколько часов.
Отсутствие дискового ввода-вывода означает, что запросы поступают в основном из ОЗУ. Если у вас «внезапно» ваши горячие столы больше не помещаются в ОЗУ, и сервер начинает работать с дисками, вас может ждать плохая поездка. 2 ГБ или ОЗУ в наши дни не так уж и много, но в эпоху SQL2000 это было бы довольно много. Я предполагаю, что объем данных, которыми обычно управляет приложение, меньше, чем имеющаяся у вас оперативная память. Возможно, вы захотите посмотреть количество «использованного» пространства в файлах данных. Это даст вам представление о том, сколько оперативной памяти может потреблять база данных в худшем случае. SQL Server не хранит данные, которые ему не нужны, в ОЗУ, но бывает сложно узнать, какие таблицы используются и когда.
Гиперпоточность не всегда помогает с SQL Server. Вы можете повысить производительность, отключив его. Трудно проверить, потому что включение и выключение требует перезагрузки, а это большая проблема на рабочем сервере.
«Сотни тысяч запросов в минуту» означает тысячи запросов в секунду. Звучит довольно загруженно, но большая часть этого трафика может быть просто выборкой курсора Access. Доступ особенно плохо подходит для эффективного получения наборов результатов из SQL. Вы можете повысить производительность, отключив параметр распараллеливания SQL Server.
Вы также хотите искать блокировки. Использование оборудования для решения проблемы блокировки не всегда приводит к ожидаемому значительному улучшению. Если блокировки не так много и запросы удовлетворяются за счет ОЗУ, а не диска, вы в основном полагаетесь на ворчание процессора и его способность перемещать данные по каналам памяти. В этом случае более быстрое оборудование должно обеспечить хорошее улучшение. Если вы спешите (чтобы решить эту проблему) и медленно растете, этого может быть достаточно.
Как решение, добавление оборудования не масштабируется так же хорошо, как улучшения базы данных. Если вы заметите всплеск роста, ваше новое оборудование может столкнуться с проблемами. Другая мысль заключается в том, что успешные приложения привлекают пользователей. Если приложение станет более отзывчивым, пользователи с большей вероятностью будут запускать больше отчетов и тому подобное, чем если бы им нужно было пойти выпить кофе, ожидая завершения отчета.
Если схема базы данных действительно плохая, вы можете добиться некоторого выигрыша в производительности, просто взглянув на индексирование таблиц. Сконцентрируйтесь на таблицах, которые, как вы знаете, часто запрашиваются. Вы можете использовать Profiler для отслеживания запросов, выполняемых к серверу, просто скажите ему искать запросы, которые читают много данных (например, 100 000 страниц), а затем работать с запросами, которые мало читают. Вы упомянули, что у некоторых таблиц нет ключей. Есть ли в данных естественные ключи, которые не применяются ограничениями или уникальными индексами?
Есть ли у таблиц кластерные индексы? Отсутствие кластерной индексации может вызвать всевозможные побочные эффекты.
Есть ли много некластеризованных индексов с большим количеством столбцов? Часто это попытка создать множество покрывающих индексов, а не реализация более эффективной стратегии индексирования. SQL Server может эффективно создавать покрывающие индексы «на лету» во время выполнения запроса, если это имеет смысл и есть поддержка некластеризованных и кластеризованных индексов.
Наконец, стоит спросить: проводится ли обслуживание таблиц (переиндексация и / или обновление статистики)?
это деловой вопрос, а не технический вопрос.
Как владелец бизнеса: Насколько стратегична система для бизнеса? чем менее стратегически важен вопрос, тем меньше я забочусь и чиню его и потраченные деньги - это деньги, которые я мог бы использовать в другом месте для развития своего бизнеса.
Компьютерный народ пугает меня, когда все входят в большую комнату, спорят о дизайне и обходятся мне в целое состояние. Продолжайте работу системы! означает ли это настройку производительности (без изменения архитектуры) или добавление дополнительных аппаратных средств, это только приоритет, если он перестает работать.
Как ИТ-консультант: Ваша система является устаревшей и требует скрытых операционных затрат. Мы можем разработать подходящую для вас систему, которая будет масштабироваться и обеспечит платформу для будущего роста и стратегического преимущества. Подпишитесь здесь и все ваши мечты сбудутся.
Как ИТ-сотрудник: Я могу быть здесь супергероем и спасти компанию, предотвратив неминуемую катастрофу, чертовски оптимизировав эту штуку! мой менеджер осыпает меня подарками и похвалами, так как я спас компании тысячи.
Ну ... это было недавно, но я решил записать результат здесь.
В конце концов, я прошел по VBA строка за строкой, чтобы разобраться с другой проблемой. Именно тогда я понял, что некоторые вызовы для получения наборов строк блокируются на 20–30 секунд.
Когда я углубился в них, я обнаружил, что набор строк основан на запросе MS Access.
Это был выбор данных из другого запроса Access.
Это был выбор данных из еще одного запроса Access.
Все это выглядело так, как будто их перетащили вместе с помощью конструктора запросов.
Я просмотрел полдюжины основных проблемных точек пользователей и обнаружил, что все они в обязательном порядке были такими же, как и эта.
Поэтому я полностью удалил стеки связанных запросов и заменил каждый из них одним сквозным запросом, который можно было бы написать на T-SQL и выполнить непосредственно на сервере.
Улучшение было абсолютно значительным в каждом случае, без сбоев, и больше не нужно было ждать запросов ни от кого.
А потом я ушел из компании. Не знаю, там ли он еще ... но я не скучаю по нему.
Здесь уже есть несколько хороших ответов, но могу ли я просто указать, что (при условии, что есть собственные разработчики) относительно небольшой объем работы будет иметь большое влияние - добавьте первичные ключи (вам даже не нужно менять все свои запросы на используйте их), добавьте индексы к используемым вами полям и немного настройте свои запросы, и вы можете увидеть абсолютно огромный рост. Купите себе немного оперативной памяти, чтобы выиграть время и запас, чтобы исправить это, а затем приступайте к работе.
Что касается вопроса «исправить или отказаться от этого», если функции системы в основном работают для вас и делают то, что вам нужно, не переписывайте колесо. Если вашим пользователям приходится заниматься гимнастикой, чтобы использовать эту вещь, потому что она не соответствует вашим потребностям, тогда нет смысла прилагать к ней усилия.
Я говорю и то и другое.
Прямо сейчас ваш процессор на 40% или около того, вы сказали? Вы еще не жалуетесь (много)? Если нет, у вас еще есть передышка. Большего объема памяти может хватить на какое-то время.
Вопрос к дальнейшему пути, есть ли у вас собственные разработчики программного обеспечения? Если ответ отрицательный, даже не пытайтесь переделать его. Вы окажетесь именно там, где находитесь сейчас.
Если у вас есть штатные разработчики, могут ли ваши штатные разработчики правильно выполнить проект? Я говорю о спецификациях полностью, должным образом (релятивно), в основном так же, как если бы это был проект заказчика. Если нет, то не беспокойтесь, иначе он вернется туда, где вы сейчас находитесь.
Пока компании не осознают, что они сами являются клиентами и им нужно предоставлять те же ресурсы для внутренних проектов, вы окажетесь именно там, где находитесь сейчас. Был там, сделал это, получил целый комод футболок.
Так что, если вы не можете сделать это должным образом, у вас есть два варианта «под ключ» из коробки, которые ваши сотрудники возненавидят, потому что теперь вы должны соответствовать форме системы, которую вы покупаете. Или его можно будет настроить, и вам все равно придется потратить время ПРОЕКТА на его настройку.
ИЛИ Реорганизуйте то, что у вас есть. Помните, что люди будут ожидать такой же полной функциональности, когда появится новый, поэтому в любом другом случае вам нужно делать все сразу. Если вы перефакторите его, у вас будет шанс выяснить, как он работает, и тогда вы будете планировать его во многих небольших подпроектах, а не на случайные изменения.
Не видя системы, я бы, вероятно, постарался максимально нормализовать серверную часть, перенести как можно больше SQL в хранимые процессы. Затем создайте новый интерфейс на основе C # Forms или веб-приложения. Если вы можете получить свою бизнес-логику и SQL из внешнего интерфейса, позже будет проще сделать это заново. Сохраняя то, что вы делаете с небольшими проектами, если они в любой момент будут отложены или остановлены, вы добьетесь прогресса, который будет использован.
Технический ответ:
У вас есть ряд предложений о том, что первичные ключи и индексация должны быть тщательно проверены. Access также очень любит использовать столбец SQL Server TimeStamp, также известный как RowVersion, в каждой таблице, поскольку это сокращает много времени, которое Access тратит на определение того, была ли изменена запись, когда дело доходит до обновления записей.
Деловой ответ:
Новое решение CRM - это большая работа по обучению людей, и вы никогда не получите систему, которая точно соответствует вашим бизнес-требованиям.
Я бы нашел хорошего специалиста по Access, который также хорошо разбирается в SQL Server, и попросил бы его потратить 3 или 6 месяцев на нормализацию таблиц и устранение болевых точек пользователей. Убедитесь, что человек работает на этих этажах как ваши пользователи, хотя и находится в тихом месте и доступен. Хотя и не слишком доступно. Разработчики не любят перерывов. S
Это требует полной реструктуризации (перестройки). Восстановите систему с нуля. Это значительно сэкономит вам в долгосрочной перспективе (накладные расходы на обслуживание). А пока бросьте на это оборудование. Я думаю, что этот вопрос - скорее «бизнес-случай», чем технический запрос. С технической точки зрения, ответ - прямое «бросьте на это больше силы». С точки зрения бизнеса, создайте новую систему!
Я отправляю отдельный ответ, а не просто добавляю Дейтонский ответ потому что есть затраты, которые не принимаются во внимание несколькими первыми людьми, отправившими ответ: стоимость переподготовки пользователей и стоимость изменения ваших бизнес-процедур для соответствия новой программе. Иначе то, что он сказал.
Одна из основных причин, по которой компании разрабатывают собственное программное обеспечение, заключается в том, что их бизнес-процедуры не соответствуют тому, что есть на рынке. И это здорово - индивидуальные бизнес-процедуры компании составляют значительную часть ценности, которую компания приносит, и ЯВЛЯЮТСЯ конкурентным преимуществом, которое компания имеет над остальным рынком. Чтобы заменить программное обеспечение чем-то универсальным, вам потребуется переобучить своих сотрудников и пожертвовать конкурентным преимуществом, либо вам придется настроить решение в соответствии с вашими бизнес-процессами. Оба варианта дороги и требуют много времени. Как бизнес-консультант, а также как системный администратор, я видел, как эти затраты убивают небольшие компании сами по себе.
Судя по вашим утверждениям, вы в значительной степени связаны процессором / программным обеспечением. Я бы сделал две вещи - добавил индексы (в определенных пределах), особенно для столбцов, которые в настоящее время их не используют. И я бы выбрал самый быстрый набор процессоров, который вы можете для этого, потому что похоже, что это то место, где вы привязываетесь, если у вас не так много операций чтения с диска, кроме как на пике.
(Кроме того, я бы, насколько это возможно, обновил серверную версию - к тому времени, когда вы установите ее на место, Access 2000 и SQL Server 2000 исполнится десять лет. Это СТАРЫЕ компьютерные годы!)
Во-первых, я согласен с Кайлом Ходжсоном и добавляю ПК. Это дешево (только время), и вы можете увидеть рост ваших запросов. А как насчет индексов столбцов соединения в 10 самых уродливых запросах? Где сканы таблицы?
Во-вторых, как насчет обрезки данных в базе данных? Возвращается ли в запросах больше строк, чем действительно необходимо? Я также согласен с предложением Кайла оперативной памяти (еще два ГБ).
Поместите все это в свой отчет (Джозеф Керн) о том, что вы предлагаете на время, пока планируете будущее. Спросите у руководства и пользователей, что происходит с организацией, если текущее приложение CRM вылетает из строя и становится недоступным. Возможно, это поможет им задуматься о будущем.
Вы упомянули оперативную память и процессоры, но не диски. Я признаю, что прошло почти десять лет с тех пор, как я имел дело с MS SQL Server, но он привязан к дискам так же, как и любая другая база данных, если не может вместить все в памяти.
Я бы, вероятно, сначала попробовал заполнить машину как можно большим объемом оперативной памяти, а затем убедился бы, что журналы записываются на диски, которые не используются для таблиц или индексов. Затем я бы попытался убедиться, что индексы таблиц не находятся на одном шпинделе.
После этого я бы стал беспокоиться о настройке уровня базы данных, но с этим вам нужно будет определить свои тесты и цель оптимизации, чтобы не нарушать работу и не ухудшать запросы. Хотя вы сказали, что первичные ключи не показали большого преимущества в вашей тестовой базе данных, вам следует взглянуть на свою методологию тестирования - первичные ключи могут позволить некоторым базам данных (не уверен, является ли MS SQL одним из них) использовать блокировку уровня записи , а не блокировки на уровне таблицы, которые могут уменьшить конкуренцию, которая может не проявляться при тестировании только с несколькими пользователями.
Учитывая ваше описание, создание совершенно новой индивидуальной системы бессмысленно - вы закончите там, где начали, или, возможно, даже хуже, чем сейчас. Поэтому, если вы не можете убедить кого-то купить стороннее решение, лучше всего провести рефакторинг, насколько это возможно, и использовать оборудование.
Я бы сказал, что вам нужно сделать две вещи: 1) Анализ производительности на сервере SQL. Похоже, вы определили серверную сторону как источник задержек, поэтому теперь вам нужно знать, какие запросы отстают и почему. По всей вероятности, вы можете найти несколько горячих точек для оптимизации, которые дадут вам большие преимущества. Черт возьми, если у вас есть клиенты, которые обновляются каждые несколько секунд, посмотрите, можете ли вы уменьшить их частоту обновления (ДЕЙСТВИТЕЛЬНО ли нужно обновлять список на экране каждые 5 секунд? Будет ли 30? Если нет, как насчет 15? ). Глупые вещи, такие как увеличение таймеров обновления, могут сэкономить вам много накладных расходов, если вам это удастся.
2) Добавьте к нему больше оборудования. ОСОБЕННО бросайте в него огромное количество таранов. Вам нужно столько памяти, чтобы база данных полностью умещалась в ОЗУ. Следите за своей ОС и версиями программного обеспечения (есть по-видимому довольно много правил с версиями Windows и каким оборудованием они на самом деле поддерживают). Если вы можете убедить себя, что больше ядер может помочь, тогда добавьте столько процессоров и ядер, сколько сможете.
В конечном итоге вам, вероятно, лучше всего будет переделать базу данных. Добавление большего количества оборудования на некоторое время решит вашу проблему, но если вы продолжите использовать его, через некоторое время вам придется добавить больше оборудования.
Обычно, когда возникают проблемы с производительностью, вы смотрите на такие вещи, как узкие места ввода-вывода на жестких дисках / RAID, сегментирование базы данных и т. Д., Но для таких вещей, как сегментирование, вам нужно, чтобы база данных была правильно спроектирована, чтобы воспользоваться этим. Судя по звукам, ваше приложение никогда не сможет масштабироваться.
В конечном итоге переделка базы данных и внешнего программного обеспечения для лучшего отражения текущих бизнес-потребностей поможет вам в долгосрочной перспективе. Ваши пользователи будут вам благодарны, ваше оборудование прослужит дольше и сэкономит гораздо больше денег в долгосрочной перспективе, чем использование гигантского оборудования.
Использование оборудования только поощряет плохой дизайн и управление, пока система не станет настолько жалкой, что не сможет работать даже на новейшем и лучшем оборудовании. Пришло время взглянуть на лучшую реализацию. Сначала проанализируйте, что требуется. Только когда вы полностью поймете требования, вы сможете найти лучший способ их реализации. Как только вы убедитесь, что понимаете требования, начните искать, что лучше / дешевле изменить то, что у вас есть, или начать с нуля, возможно, с чего-то совершенно другого.
Исходя из предоставленной информации, я бы заменил систему. Желательно с другой CRM, которая позволяет гибкую интеграцию с другими системами (что может поставить под угрозу вашу ERP IS).
Самая сложная часть - убедить руководство и пользователей в необходимости обновления.
Управление
Выскажите свое беспокойство по поводу технических проблем, низкой производительности, опасений византийских сбоев и т. Д. Затем представьте 2 альтернативных CRM. Поговорите об интеграции бизнеса, общей стратегии ERP для бизнеса и, самое главное, о том, как это сделает сотрудников более продуктивными и прибыльными. Примеры использования. Сделайте это не дольше 15 минут (если им не нужна дополнительная информация). Затем вам нужно убедить пользователей.
Пользователи
Планы обучения (которые может предоставить поставщик [и руководство должно будет одобрить]), постоянное общение с верхними 20% ваших пользователей (опытные пользователи, вызывающие проблемы) и твердое обязательство по поддержанию работоспособности системы на 100% за первый месяц (первый месяц повлияет на любую новую IS).
Существует множество продуктов CRM, выберите тот, который лучше всего соответствует потребностям вашего бизнеса.
Получите оборудование!
Мало того, что олово сейчас очень дешево, если вы выберете чип серии Xeon 55xx, он будет кричать обо всем, что вы можете в него бросить.
Это просто вопрос риска / вознаграждения - вы можете потратить деньги и много времени на улучшение БД или купить себе дорогу быстрее и дешевле.
Подумайте о том, чтобы перевернуть 3 ГБ памяти переключить и добавить еще 2 ГБ памяти.