Масштабирование базы данных RT
Да!
Я сказал бы, что проводник процесса является, возможно, одним из самых удобных инструментов там. Я использую его больше, чем почти какой-либо другой инструмент диагностики для окон. Чтобы действительно получить все возможное от него однако, действительно необходимо включить историю ЦП, историю Памяти и историю ввода-вывода. Это действительно дает Вам всю информацию, необходимо диагностировать наиболее распространенные раздражения окон как подвешенные процессы и приложения, которые, кажется, замедляют других. Это - также хороший способ определить приложения, которые имеют утечки памяти. Те, кто выполняет устойчивые системы, которые могут пойти в течение многих недель без катастрофического отказа, находят что одна функция особенно полезный.
Как занятый Вы ожидаете, что средство отслеживания ошибки будет? Мое подозрение - то, что рабочий набор является относительно небольшим, и должен легко кэшироваться DB.
Единственные сообщения о проблемах масштабирования RT, которые я могу найти, с 2003, и только в поиске. Основные пользователи RT, вероятно, будут электронной почтой, которая должна быть относительно легкой по сравнению со случайными поисковыми запросами DB.
Я работал в компании, которая имела сотни тысяч билетов в RT, и прежде чем резкий спам-фильтр был помещен, на месте добавлял несколько тысяч новых билетов в день из-за одного только спама.
Будучи на поле, которое по сегодняшним стандартам является древним (класс P4) это никогда не имело проблему производительности. Это главным образом останавливает от использования правильно управляемую Пост-ГРЭС как бэкенд, MySQL хорошо работает, но RT просто лучше оптимизирован для него.
Можно сказать RT производить чистку старых билетов, но это уничтожает данные и пустую трату времени, по моему скромному мнению.