Цитата:
Сообщение от
Evgeniy2020
Тема вопроса повышение быстродействия системы.
Есть компания, она растет, количество пользователей растет, база тоже растет.
вопрос какие существуют возможности по аппаратному увеличению производительности системы?
Что-то сегодня день тяжелый.
Я конечно понимаю, что "не бывает плохих вопросов, бывают только плохие ответы".
Но что из уже существующего вы видели?
например,
http://axapta.mazzy.ru/lib/querytuning/ (для современных аксапт нужно искать по ключевому слову TraceParser)
http://axapta.mazzy.ru/lib/axapta_itanium/
http://axapta.mazzy.ru/lib/axapta_benchmark/
И про какую версию Аксапты вы спрашиваете?
Цитата:
Сообщение от
Evgeniy2020
1. Например на сервере MS SQL использовать SSD диски (они вроде быстрее работают чем обычные магнитные), стоит ли использовать RAID на основе SSD?
Мое личное мнение - пока это дорого и ненадежно.
Если вы только начали заниматься производительностью, то начните с более простых, дешевых и надежных шагов - просто займитесь индексами.
Цитата:
Сообщение от
Evgeniy2020
2. насколько я понимаю 32 битные версии Аксапты могут видеть только до 4 ГБ оперативной памяти. Стоит ли на АОС ставить больше чем 4 Гб?
Для 32битной - не стоит.
Если у вас ax2009, то просто используйте 64битную. для нее вполне стоит.
Цитата:
Сообщение от
Evgeniy2020
3. По поводу MS SQL Server то его можно ставить на 64 битную ОС,
и там можно наращивать память. Вопрос если уже стоит машина
с 32 Гб ОЗУ и в системном мониторе 6 процессоров.
стоит ли скажем при размере базы в 55 ГБ переходить на 64 ГБ ОЗУ
даст ли это существенный пирост скорости?
нет. займитесь индексами.
обратите внимание, что никогда не стоит задача "загрузить всю базу в ОЗУ"
всегда стоит задача "загрузить самые часто испольуемые индексы в ОЗУ (в кэш)"
Есть даже показатель (счетчик) "Cache Hit Ratio". Рекомендуется, что он должен быть не менее 95%. По этому поводу нужно читать руководства и ресурсы по самому SQL.
Цитата:
Сообщение от
Evgeniy2020
4. По поводу сети, есть ли смысл между АОС и MS SQL Server ставить Gigabit Ethernet? или даже 10 Gbit Ethernet?
Да, если показатель (счетчик) "Network utilization %" превышает некий предельный уровень. Для начала используйте уровень 30%. Реальное значение сильно зависит от топологии вашей сети (например, этот канал используется только для AOS и SQL? или на этом канале находятся и обычные пользвотели?)
Про утилизацию читайте доку по сетям и ресурсы по ним же.
Если вы не знаете что это за показатель и даже предположить не можете какой пороговый уровень будет адекватным для вас, то исходите из того, что замена сети вам НЕ поможет.
Цитата:
Сообщение от
Evgeniy2020
стоит ли ключевых пользователей подключать к такому Гигабитному ethernet или это не даст увеличение производительности системы?
Если система написана правильно (в соответствии с рекомендациями Best Practice), то не нужно. Мало того, подключение пользователей к каналу AOS-SQL здорово снизит критический пороговый уровень утилизации сети.
Если же у вас много кастомизаций, причем таблицы дергаются в формах, то гигабитный канал вам не поможет
Не поможет и 10гигабитный, и 100гигабитный. Нужно переписывать запросы.
Цитата:
Сообщение от
Evgeniy2020
я встречал на Аксапте базы и 300 GB хотя трудноывто представить сервер, на котором это должно работать эффективно, особенно отчеты за весь период.
Сервер представить легко. Он же не берет все данные сразу. Он же с индексами работает.
Кроме того:
1. не нужно делать отчеты "за весь период". См.
http://axapta.mazzy.ru/lib/inventsumdate/
то, что делает локализация и буржуйские разработчики в последних версиях системы для получения отчетов "от начала времен" - вредительство. Не делайте так.
2.
когда говорите "база 300Гб", то четко разделяйте размер данных и размер лога.
Я тоже видел базы, у которых Recovery Mode находится в режиме Full и не бэкапируются. Там данные занимали гиг 20, а остальные сотни гигабайт - transaction log.
Надеюсь, что это не ваш случай.
Тогда вам обязательно надо познакомиться с
http://axapta.mazzy.ru/lib/dbgrowthsolution/
дело в том, что база данных Аксапты содержит очень много логов, которые нужно чистить.
Очень часто об этом "забывают".
Цитата:
Сообщение от
Evgeniy2020
можно ли еще как то увеличивать быстродействие не уменьшая базы данных?
и вообще какие способы наиболее эффективны
Займитесь индексами.
Шаг номер 0: посмотрите в счетчики и узнайте сколько Full Scan'ов у вас выполняется. Добавляя индексы, снизьте это количество по крайней мере в 100 раз (а лучше доведите до 0).
После этого можно выполнять остальные шаги: по чистке базы, оптимизации индексов, убиранию лишних индексов.