ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
25 сообщений из 67, страница 2 из 3
  2  все
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902183
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
alexeyvg
hichnik_andrei
Обслуживание базы происходит таким образом
Аааа! Там Шринк делается???


Да
...
Рейтинг: 0 / 0
12.12.2019, 22:03
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902185
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
Yasha123
да у вас блокировок воз и тележка,
вот почему рестарт и помогает.
надо смотреть, кто таблицы целиком лочит.
например, апдэйты миллиона строк на стейтмент


Как-нибудь точнее можно?
...
Рейтинг: 0 / 0
12.12.2019, 22:05
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902187
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
hichnik_andrei
alexeyvg
пропущено...
Аааа! Там Шринк делается???


Да
Шринк вообще говоря операция аварийная, как, например, рестор базы.

Если вы его делаете для файлов базы, то это замедляет работу базы из за сильной фрагментации.
Если вы его делаете для файлов лога, то это замедляет работу базы из за необходимости увеличивать лог после уменьшения.
Особенно печально, если для файла установлено маленькое автоувеличение, например, 1 мб - тогда этом может вызывать заметное замедление.
Идеально - установить достаточные размеры файлов базы, и шринк не делать.
...
Рейтинг: 0 / 0
12.12.2019, 22:08
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902188
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
hichnik_andrei,

ну шринк конечно зло, но это не объясняет поведения почему после рестарта как ТС говорит проблема исчезает.

покажите на всякий случай
Код: sql
1.
select /*[name],*/ [is_auto_shrink_on], [is_auto_update_stats_on], [is_auto_update_stats_async_on], [is_parameterization_forced], [log_reuse_wait_desc] from sys.databases;



вам бы диагностику проводить именно тогда когда вы на сервере реально наблюдаете проблемы производительности.
...
Рейтинг: 0 / 0
12.12.2019, 22:09
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902190
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
alexeyvg,

Да шаг 1Мб, сколько лучше сделать?
...
Рейтинг: 0 / 0
12.12.2019, 22:14
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902194
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Можно включить оценку унаследованную кратности (legacy cardinality estimation) для базы и понаблюдать. Если поможет - то так и оставить.
...
Рейтинг: 0 / 0
12.12.2019, 22:18
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902195
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
[quot felix_ff#22039191]hichnik_andrei,

покажите на всякий случай
Код: sql
1.
select /*[name],*/ [is_auto_shrink_on], [is_auto_update_stats_on], [is_auto_update_stats_async_on], [is_parameterization_forced], [log_reuse_wait_desc] from sys.databases;
...
Рейтинг: 0 / 0
12.12.2019, 22:19
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902196
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
hichnik_andrei,

давайте уж в догонку тогда подробности глянем:
Код: sql
1.
2.
3.
4.
5.
6.
select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Locks' and [counter_name] in ('Lock Requests/sec', 'Lock Timeouts/sec', 'Number of Deadlocks/sec', 'Lock Waits/sec')
union
select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Databases' and [counter_name] in ('Log Flush Waits/sec', 'Log Flush Wait Time')
union
select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Wait Statistics'
order by [counter_name], [instance_name], [cntr_value] desc
...
Рейтинг: 0 / 0
12.12.2019, 22:21
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902198
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
felix_ff,

пару мин и сброшу, бэкап по расписанию делается
...
Рейтинг: 0 / 0
12.12.2019, 22:26
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902202
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
felix_ff
hichnik_andrei,

Код: sql
1.
2.
3.
4.
5.
6.
select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Locks' and [counter_name] in ('Lock Requests/sec', 'Lock Timeouts/sec', 'Number of Deadlocks/sec', 'Lock Waits/sec')
union
select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Databases' and [counter_name] in ('Log Flush Waits/sec', 'Log Flush Wait Time')
union
select [counter_name], [instance_name], [cntr_value] from sys.dm_os_performance_counters where [object_name] = 'SQLServer:Wait Statistics'
order by [counter_name], [instance_name], [cntr_value] desc



Модератор: Вложение удалено.

Модератор: Вложение удалено.
...
Рейтинг: 0 / 0
12.12.2019, 22:36
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902203
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
hichnik_andrei,

вы если в текущий (прямо сейчас) момент проблемы с производительностью наблюдаете

то используйте или процедуру sp_WhoIsActive она информативнее
или прям запрос выполните:
Код: sql
1.
2.
3.
4.
  select [session_id], [exec_context_id], [blocking_session_id], [blocking_exec_context_id], [wait_duration_ms], [wait_type], [resource_description] 
  from sys.dm_os_waiting_tasks 
  where [blocking_session_id] is not null 
     or [wait_duration_ms] > 10000



если возвращаются строки с каким либо достаточно долгим wait_type надо предметно разбираться что и кого сессии ждут.
...
Рейтинг: 0 / 0
12.12.2019, 22:36
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902205
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
hichnik_andrei,

картинка для китайцев. вы сами можете разобрать что там нарисованно? :)
...
Рейтинг: 0 / 0
12.12.2019, 22:37
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902207
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
felix_ff,

редактировал уже)))
...
Рейтинг: 0 / 0
12.12.2019, 22:39
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902208
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
felix_ff,
...
Рейтинг: 0 / 0
12.12.2019, 22:40
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902209
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
felix_ff,
...
Рейтинг: 0 / 0
12.12.2019, 22:40
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902236
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yasha123
Участник
hichnik_andrei
Yasha123
да у вас блокировок воз и тележка,
вот почему рестарт и помогает.
надо смотреть, кто таблицы целиком лочит.
например, апдэйты миллиона строк на стейтмент


Как-нибудь точнее можно?

статистику соберите хотя бы за сутки,
т.е. не рестарьте сервер каждый час.
но даже за короткий период у вас на первом месте LCK_M_IX.
значит, или на страницы, или на таблицы целиком ждут IХ.
это означает, что кто-то апдэйтит тучу строк за 1 стэйтмент,
раз там уже чей-то Х
...
Рейтинг: 0 / 0
12.12.2019, 23:44
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902237
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
hichnik_andrei
Да шаг 1Мб, сколько лучше сделать?

Шаг 1 Гб, нормально.
...
Рейтинг: 0 / 0
12.12.2019, 23:45
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902239
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
hichnik_andrei,

Счётчики (и вообще результаты запросов) лучше копировать из SSMS, и выкладывать в таблице CSV=t и в спойлере:
 
Lock Requests/sec _Total 52260990Lock Requests/sec AllocUnit 1Lock Requests/sec Application 250Lock Requests/sec Database 18206841Lock Requests/sec Extent 7874Lock Requests/sec File 742Lock Requests/sec HoBT 6959Lock Requests/sec Key 18109556Lock Requests/sec Metadata 7977709Lock Requests/sec Object 7903269Lock Requests/sec OIB 0Lock Requests/sec Page 38203Lock Requests/sec RID 9586Lock Requests/sec RowGroup 0Lock Timeouts/sec _Total 417Lock Timeouts/sec AllocUnit 0Lock Timeouts/sec Application 0Lock Timeouts/sec Database 0Lock Timeouts/sec Extent 0Lock Timeouts/sec File 0Lock Timeouts/sec HoBT 0Lock Timeouts/sec Key 413Lock Timeouts/sec Metadata 2Lock Timeouts/sec Object 2Lock Timeouts/sec OIB 0Lock Timeouts/sec Page 0Lock Timeouts/sec RID 0Lock Timeouts/sec RowGroup 0Lock waits Average wait time (ms) 0Lock waits Cumulative wait time (ms) per second 0Lock waits Waits in progress 0Lock waits Waits started per second 0Lock Waits/sec _Total 727Lock Waits/sec AllocUnit 0Lock Waits/sec Application 0Lock Waits/sec Database 16Lock Waits/sec Extent 0Lock Waits/sec File 0Lock Waits/sec HoBT 0Lock Waits/sec Key 7Lock Waits/sec Metadata 10Lock Waits/sec Object 694Lock Waits/sec OIB 0Lock Waits/sec Page 0Lock Waits/sec RID 0Lock Waits/sec RowGroup 0Log buffer waits Average wait time (ms) 0Log buffer waits Cumulative wait time (ms) per second 0Log buffer waits Waits in progress 0Log buffer waits Waits started per second 0Log Flush Wait Time _Total 6809Log Flush Wait Time db1 4Log Flush Wait Time db2 0Log Flush Wait Time distribution 1278Log Flush Wait Time DWConfiguration 7Log Flush Wait Time DWDiagnostics 0Log Flush Wait Time DWH_STAGE 5Log Flush Wait Time DWQueue 0Log Flush Wait Time LibRusEc 5Log Flush Wait Time LinkedIn 6Log Flush Wait Time master 1944Log Flush Wait Time MLS 0Log Flush Wait Time model 0Log Flush Wait Time msdb 3486Log Flush Wait Time mssqlsystemresource 0Log Flush Wait Time ReportServer 2Log Flush Wait Time ReportServerTempDB 1Log Flush Wait Time SSISDB 4Log Flush Wait Time tempdb 2Log Flush Wait Time test 19Log Flush Wait Time test_mydb1 2Log Flush Wait Time TestBackupRestore 2Log Flush Wait Time TestPartition 0Log Flush Wait Time Tfs_DefaultCollection 34Log Flush Wait Time user_sysres 8Log Flush Waits/sec _Total 14992Log Flush Waits/sec db1 3Log Flush Waits/sec db2 3Log Flush Waits/sec distribution 3506Log Flush Waits/sec DWConfiguration 3Log Flush Waits/sec DWDiagnostics 2Log Flush Waits/sec DWH_STAGE 2Log Flush Waits/sec DWQueue 2Log Flush Waits/sec LibRusEc 4Log Flush Waits/sec LinkedIn 2Log Flush Waits/sec master 6740Log Flush Waits/sec MLS 3Log Flush Waits/sec model 5Log Flush Waits/sec msdb 4646Log Flush Waits/sec mssqlsystemresource 0Log Flush Waits/sec ReportServer 3Log Flush Waits/sec ReportServerTempDB 2Log Flush Waits/sec SSISDB 4Log Flush Waits/sec tempdb 18Log Flush Waits/sec test 26Log Flush Waits/sec test_mydb1 3Log Flush Waits/sec TestBackupRestore 3Log Flush Waits/sec TestPartition 2Log Flush Waits/sec Tfs_DefaultCollection 8Log Flush Waits/sec user_sysres 2Log write waits Average wait time (ms) 0Log write waits Cumulative wait time (ms) per second 0Log write waits Waits in progress 0Log write waits Waits started per second 0Memory grant queue waits Average wait time (ms) 0Memory grant queue waits Cumulative wait time (ms) per second 0Memory grant queue waits Waits in progress 0Memory grant queue waits Waits started per second 0Network IO waits Average wait time (ms) 0Network IO waits Cumulative wait time (ms) per second 0Network IO waits Waits in progress 0Network IO waits Waits started per second 0Non-Page latch waits Average wait time (ms) 0Non-Page latch waits Cumulative wait time (ms) per second 0Non-Page latch waits Waits in progress 0Non-Page latch waits Waits started per second 0Number of Deadlocks/sec _Total 0Number of Deadlocks/sec AllocUnit 0Number of Deadlocks/sec Application 0Number of Deadlocks/sec Database 0Number of Deadlocks/sec Extent 0Number of Deadlocks/sec File 0Number of Deadlocks/sec HoBT 0Number of Deadlocks/sec Key 0Number of Deadlocks/sec Metadata 0Number of Deadlocks/sec Object 0Number of Deadlocks/sec OIB 0Number of Deadlocks/sec Page 0Number of Deadlocks/sec RID 0Number of Deadlocks/sec RowGroup 0Page IO latch waits Average wait time (ms) 1Page IO latch waits Cumulative wait time (ms) per second 0Page IO latch waits Waits in progress 0Page IO latch waits Waits started per second 3Page latch waits Average wait time (ms) 0Page latch waits Cumulative wait time (ms) per second 0Page latch waits Waits in progress 0Page latch waits Waits started per second 0Thread-safe memory objects waits Average wait time (ms) 0Thread-safe memory objects waits Cumulative wait time (ms) per second 0Thread-safe memory objects waits Waits in progress 0Thread-safe memory objects waits Waits started per second 0Transaction ownership waits Average wait time (ms) 0Transaction ownership waits Cumulative wait time (ms) per second 0Transaction ownership waits Waits in progress 0Transaction ownership waits Waits started per second 0Wait for the worker Average wait time (ms) 0Wait for the worker Cumulative wait time (ms) per second 0Wait for the worker Waits in progress 0Wait for the worker Waits started per second 0Workspace synchronization waits Average wait time (ms) 0Workspace synchronization waits Cumulative wait time (ms) per second 0Workspace synchronization waits Waits in progress 0Workspace synchronization waits Waits started per second 0
...
Рейтинг: 0 / 0
12.12.2019, 23:53
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902246
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
komrad
Участник
hichnik_andrei
На сервере стоит :Microsoft SQL Server 2016 (RTM) - 13.0.1601.5 (X64)

не помешает поставить хотя бы второй сервис-пак
https://sqlserverbuilds.blogspot.com/#sql2016x
...
Рейтинг: 0 / 0
13.12.2019, 00:38
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902257
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
Yasha123
hichnik_andrei
пропущено...


Как-нибудь точнее можно?

статистику соберите хотя бы за сутки,
т.е. не рестарьте сервер каждый час.
но даже за короткий период у вас на первом месте LCK_M_IX.
значит, или на страницы, или на таблицы целиком ждут IХ.
это означает, что кто-то апдэйтит тучу строк за 1 стэйтмент,
раз там уже чей-то Х


у него там их всего 40 штук и общее время ожидания было 26 секунд на все IX.
по первому скрину я бы сказал что система особо ничего и не ждет.

А вот по счетчикам можно предположить следующее:

в топах запросов блокировок два типа: Metadata и Object
на metadata причем приходится порядка 38% процентов запросов на блокировки.
на базе включен auto_update_statistics, предположительно в бд преобладает в основном Ad-Hoc нагрузка что дает такую значительную разницу в типах блокировок на метаданные. (вообще метаданных хренова туча может лочиться но чаще всего лично мне встречался stats)

на втором месте object и только после него Key следовательно достаточно часто запросы идут с локом всей кучи/кластера.
RID блокировок мало Key много, в целом по базе преобладают кластеризованные таблицы.
таймауты в основном по блокировкам ключей правда может там вообще nowait типы я с счетчиком промазал немного.


итого имхо:
по видимому у вас в бд возникают достаточно часто сканирующие запросы при этом скорее всего это ad-hoc.
Вам необходимо посмотреть степень преобладающей нагрузки на базу:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
with x as (
    select
	      pool_id,
		  cacheobjtype,
		  objtype,
		  size_in_bytes,
		  refcounts,
		  usecounts,
	      sum([size_in_bytes]) over (partition by pool_id, cacheobjtype, objtype order by 1/0) * 100 / sum([size_in_bytes]) over () as [percentage]
   from sys.dm_exec_cached_plans
)
select pool_id, 
	   cacheobjtype,
	   objtype,
       sum(size_in_bytes) as [bytes],
	   sum(refcounts) as refs,
	   count(1) as cnt,
	   sum(usecounts) as [uses],
	   max(percentage) as [percentage]
from x
group by pool_id, cacheobjtype, objtype



если процентно преобладает Adhoc посмотрите в сторону
Код: sql
1.
sp_configure 'optimize for ad hoc workloads'


если 0 можно поставить в 1

необходимо предметно смотреть почему так часто вызываеются блокировки объектов вместо ключей => недостающие/неоптимальные индексы на таблицах

если ad-hod нагрузка значительно преобладает над Proc, и вы знаете что на бд много пишушей нагрузки то auto_update_stats на базе можно или перевести в асинхронную модель или отключить и вешать отдельный джоб на обновление статистики.
...
Рейтинг: 0 / 0
13.12.2019, 01:34
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902325
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
felix_ff
если ad-hod нагрузка значительно преобладает над Proc, и вы знаете что на бд много пишушей нагрузки то auto_update_stats на базе можно или перевести в асинхронную модель или отключить и вешать отдельный джоб на обновление статистики.
У ТС в плане обслуживания обновление статистики; конечно, auto_update_stats нужно отключить.
...
Рейтинг: 0 / 0
13.12.2019, 09:52
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902359
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yasha123
Участник
felix_ff

у него там их всего 40 штук и общее время ожидания было 26 секунд на все IX.
по первому скрину я бы сказал что система особо ничего и не ждет.

на моем нынешнем месте работы картинка была ровно такая.
но не потому, что сервер "ничего не ждал",
а потому, что перегружали по неск. раз в день, когда висело вообще все.

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

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

felix_ff

необходимо предметно смотреть почему так часто вызываеются блокировки объектов вместо ключей => недостающие/неоптимальные индексы на таблицах

вот именно.
причем индексы могут даже и быть, но если способные граждане миллионы разом апдэйтят,
никакие индексы не спасут
...
Рейтинг: 0 / 0
13.12.2019, 10:45
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902647
hichnik_andrei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hichnik_andrei
Гость
Сегодня опять сервер начал тормозить, а потом выдал ошибку 1с
...
Рейтинг: 0 / 0
13.12.2019, 15:57
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902658
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yasha123
Участник
но это же 1С не хватило памяти, а не серверу.
а вы еще и недовольны, что сервер мало отъел.
...
Рейтинг: 0 / 0
13.12.2019, 16:03
| Ответить | Цитировать | Написать  
Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
    #39902660
Sergey Sizov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Sizov
Участник
hichnik_andrei,
ну вот и причина тормозов. Только к sql это не имеет ни малейшего отношения. Ибо это проблемы сервера 1с.
...
Рейтинг: 0 / 0
13.12.2019, 16:03
| Ответить | Цитировать | Написать  
25 сообщений из 67, страница 2 из 3
  2  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Помогите! Sql не использует вместо 34гб только 10-12 Гб оперативной памяти.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=39902187&tid=1686783]:
 0ms
get settings:
 7ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 47ms
get topic data:
 8ms
get forum data:
 3ms
get page messages:
 57ms
get tp. blocked users:
 2ms
others: 356ms
total:  500ms
созд. / загр.: 500ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]