#c# #sql-server #performance #garbage-collection
#c# #sql-server #Производительность #сбор мусора
Вопрос:
Я запускаю настольное приложение, построенное на C #, подключенное к базе данных Microsoft SQL Server Express. Около 20-30 пользователей обращаются к этому приложению, в то время как еще 20-30 систем подключены к базе данных одновременно, и она работает 24 часа в сутки. Операционная система работает в соответствии со стандартом Windows Server 2012.
Иногда я сталкиваюсь с серьезными проблемами производительности в приложении, когда я перезапускаю сервер, все становится нормальным.
Я уже проверил все компьютеры, и вирус не обнаружен. Похоже, что и в сетевых устройствах проблем нет.
В чем может быть проблема? Сборка мусора?
Спасибо
Комментарии:
1. Как вы обрабатываете подключение к базе данных в коде? Если вы не удаляете соединения, то возникнут проблемы с тем, что соединение не будет возвращено в пул соединений, что означает, что потоки в конечном итоге будут ждать, пока соединение станет доступным. У вас также могут возникнуть проблемы с блокировкой таблиц, когда несколько пользователей могут пытаться обновлять / вставлять, что приведет к блокировке записей или таблиц для предотвращения конфликтов. Это в сочетании с тем, что соединения не удаляются, может привести к тому, что вы описали
2. Я открываю соединения только при необходимости и закрываю в конце операции CRUD. Вот пример этого
try { } catch (Exception exp) { MessageBox.Show(exp.Message.ToString(), "Exception"); } finally { if (sqlConnection.State == ConnectionState.Open) { sqlConnection.Close(); } }3. можете ли вы проверить процессор sql Server, использование памяти, когда вы сталкиваетесь с проблемами производительности и вопросом обновления
4. @TheGameiswar есть ли какой-либо инструмент, который может помочь мне собрать данные об использовании процессора, памяти и составить отчет о сравнении на основе старого использования???
5. поиск
collect cpu performance metrics sql server
Ответ №1:
Существуют имитации для версии SQL Server Express:
-
Количество поддерживаемых процессоров: одновременно поддерживается только один процессор (максимальное количество ядер = 4 для sql express 2016). Итак, если на вашем сервере несколько процессоров, он будет использовать только один процессор одновременно.
-
Максимальная используемая память: максимум 1 ГБ памяти для буфера данных. Итак, если на вашем сервере больше ГБ памяти, SQL Server Express не сможет воспользоваться этим.
-
Ограничение размера базы данных: Максимальный размер базы данных ограничен 4 ГБ (10 ГБ для sql Express 2016)
Скорость дискового ввода-вывода и память являются одними из основных ресурсов для производительности sql. Поскольку данные находятся в кэше в течение длительного времени, сервер считывает данные из памяти, а не с диска.
Одной из мер, которые могут помочь в поиске узкого места в производительности сервера, является измерение ожидаемого срока службы страницы (PLE). Оно должно быть> 300 для сервера с 4 ГБ памяти (но на самом деле sql Express использует ограниченный 1 ГБ).
PLE — это количество секунд, в течение которых средняя страница данных находилась в буферном пуле. Хранение данных в памяти обеспечивает SQL Server более быстрый доступ к ним вместо длительного и медленного перемещения на диск. Эта мера может открыть вам глаза и привести вас к проблемам, которые можно решить. вы можете получить, выполнив:
SELECT object_name,
counter_name,
cntr_value AS [value]
FROM sys.dm_os_performance_counters
WHERE LTRIM(RTRIM(object_name)) = 'SQLServer:Buffer Manager'
AND LTRIM(RTRIM(counter_name)) = 'Page life expectancy' ;
В sql Express вы теряете ключевые ресурсы (ограничение памяти 1 ГБ), которые помогают увеличить счетчик запросов.
В вашей системе 20-30 пользователей, плюс еще 20-30 систем подключены к базе данных одновременно, и она работает 24 часа в сутки.
Лучше перейти на SQL Standard Edition 2016 без ограничений по объему памяти (до 128 ГБ) и процессору / ядрам (до 24 ядер).
Ответ №2:
Взгляните на счетчики производительности Windows.
Мой первый взгляд был бы SQLServer: диспетчер памяти: общая память сервера (КБ) и SQLServer: диспетчер памяти: память целевого сервера (КБ). Также посмотрите на буфер: счетчик коэффициента попадания в кэш.
Если объем целевой памяти превышает общий объем памяти, увеличьте объем памяти. Если коэффициент попадания в кэш в среднем ниже 99%, также увеличьте объем памяти.