MSSQLSERVER_701

platí pro:SQL Server

Podrobnosti

Attribute Value
Název produktu SQL Server
ID události 701
Zdroj události MSSQLSERVER
Součást SQLEngine
Symbolický název NOSYSMEM
Text zprávy Není dostatek systémové paměti na spuštění tohoto dotazu.

Note

Tento článek se zaměřuje na SQL Server. Informace o řešení problémů s nedostatkem paměti v Azure SQL Database naleznete v článku Řešení chyb při vyčerpání paměti pomocí Azure SQL Database.

Vysvětlení

Chyba 701 nastává, když SQL Server nedokáže přidělit dostatečnou paměť pro spuštění dotazu. Nedostatečná paměť může být způsobena řadou faktorů, jako jsou nastavení operačního systému, dostupnost fyzické paměti, využití v SQL Server jinými komponentami nebo omezení paměti na aktuální pracovní zátěž. Ve většině případů není příčinou této chyby neúspěšná transakce. Celkově lze příčiny rozdělit do tří:

Externí nebo operační paměťový tlak

Externí tlak označuje vysoké využití paměti pocházející ze strany komponenty mimo proces, což vede k nedostatečné paměti pro SQL Server. Musíte zjistit, zda jiné aplikace v systému spotřebovávají paměť a nepřispívají k nízké dostupnosti pamětí. SQL Server je jednou z mála aplikací navržených tak, aby reagovala na tlak na paměť OS snížením jeho využití. To znamená, že pokud nějaká aplikace nebo ovladač požádá o paměť, operační systém pošle signál všem aplikacím, aby uvolnily paměť, a SQL Server na to reaguje snížením vlastní spotřeby paměti. Velmi málo jiných aplikací reaguje, protože nejsou navrženy tak, aby naslouchaly takovému oznámení. Takže pokud SQL začne snižovat využití paměti, jeho paměťový fond se zmenší a komponenty, které paměť potřebují, ji nemusí získat. Začnete dostávat chyby 701 a další chyby související s pamětí. Pro více informací viz SQL Server Memory Architecture

Vnitřní tlak na paměť, který nepochází ze SQL Server

Tlak na vnitřní paměť označuje nízkou dostupnost paměti způsobenou faktory uvnitř procesu SQL Server. Existují komponenty, které mohou běžet uvnitř procesu SQL Server a jsou "externí" vůči enginu SQL Server. Příklady zahrnují DLL jako propojené servery, komponenty SQLCLR, rozšířené procedury (XP) a automatizaci OLE (sp_OA*). Mezi další patří antivirové nebo jiné bezpečnostní programy, které vkládají DLL do procesu pro účely monitorování. Problém nebo špatný návrh v kterékoliv z těchto komponent může vést k velké spotřebě paměti. Například si představme propojený server, který ukládá do paměti SQL Server 20 milionů řádků dat pocházejících z externího zdroje. Pokud jde o SQL Server, žádný paměťový úředník nehlásí vysokou spotřebu paměti, ale spotřeba paměti uvnitř procesu SQL Server bude vysoká. Tento růst paměti z propojeného serverového DLL například způsobí, že SQL Server začne snižovat využití paměti (viz výše) a vytváří nízkopaměťové podmínky pro komponenty uvnitř SQL Server, což způsobuje chyby jako 701.

Tlak na vnitřní paměť, pocházející ze komponent/komponent SQL Server

Vnitřní tlak na paměť pocházející z komponent uvnitř SQL Server Engine může také vést k chybě 701. Existují stovky komponent, sledovaných přes sys.dm_os_memory_clerks, které přidělují paměť v SQL Server. Musíte určit, kteří paměťoví úředníci jsou zodpovědní za největší alokace paměti, abyste to mohli dále vyřešit. Například pokud zjistíte, že OBJECTSTORE_LOCK_MANAGER paměťový úředník zobrazuje velkou alokaci paměti, musíte lépe pochopit, proč správce zámků spotřebovává tolik paměti. Můžete zjistit, že existují dotazy, které získávají velké množství zámků a optimalizují je pomocí indexů, nebo zkracují transakce, které drží zámky po dlouhou dobu, nebo kontrolují, zda je eskalace zámků deaktivována. Každý paměťový zapisovač nebo komponenta má jedinečný způsob přístupu k paměti a jeho používání. Pro více informací viz sys.dm_os_memory_clerks a jejich popisy.

Akce uživatele

Pokud se chyba 701 objeví občas nebo jen na krátkou dobu, může se objevit krátkodobý problém s pamětí, který se sám vyřeší. V těchto případech možná nebudete muset podnikat kroky. Pokud se však chyba vyskytuje opakovaně, na více připojeních a přetrvává několik sekund nebo déle, postupujte podle kroků pro další řešení problémů.

Následující seznam uvádí obecné kroky, které pomohou při řešení chyb v paměti.

Diagnostické nástroje a zachycení

Diagnostické nástroje, které vám umožní sbírat data o řešení problémů, jsou Sledování výkonu, sys.dm_os_memory_clerks a DBCC MEMORYSTATUS.

Nakonfigurujte a sbírejte následující čítače pomocí Sledování výkonu:

  • Paměť: Dostupná MB
  • Proces: Pracovní množina
  • Proces:Soukromé bajty
  • SQL Server:Správce paměti: (všechny čítače)
  • SQL Server:Buffer Manager: (všechny čítače)

Shromažďujte periodické výstupy tohoto dotazu na postiženém SQL Server

SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC

Pssdiag nebo SQL LogScout

Alternativním, automatizovaným způsobem, jak tyto datové body zachytit, je použití nástrojů jako PSSDIAG nebo SQL LogScout.

  • Pokud používáte Pssdiag, nakonfigurujte si zachycení Perfmon collectoru a Custom Diagnostics\SQL Memory Error collector
  • Pokud používáte SQL LogScout, nakonfigurujte scénář paměti

Následující sekce popisují podrobnější kroky pro každý scénář – vnější nebo vnitřní paměťový tlak.

Vnější tlak: diagnostika a řešení

  • Pro diagnostiku nízkých paměťových podmínek v systému mimo proces SQL Server shromáždíte čítače monitoru výkonu. Prozkoumejte, zda aplikace nebo služby jiné než SQL Server spotřebovávají paměť na tomto serveru podle těchto čítačů:

    • Paměť: Dostupná MB
    • Proces: Pracovní množina
    • Proces:Soukromé bajty

    Zde je ukázková sbírka logů Perfmon pomocí PowerShellu

    clear
$serverName = $env:COMPUTERNAME
$Counters = @(
   ("\\$serverName" +"\Memory\Available MBytes"),
   ("\\$serverName" +"\Process(*)\Working Set"),
   ("\\$serverName" +"\Process(*)\Private Bytes")
)

Get-Counter -Counter $Counters -SampleInterval 2 -MaxSamples 1 | ForEach-Object  {
$_.CounterSamples | ForEach-Object       {
   [pscustomobject]@{
      TimeStamp = $_.TimeStamp
      Path = $_.Path
      Value = ([Math]::Round($_.CookedValue, 3)) }
}
}

  • Prohlédněte si log systémových událostí a hledejte chyby související s pamětí (například nízká virtuální paměť).

  • Zkontrolujte, zda protokol událostí aplikace neobsahuje problémy s pamětí související s aplikací.

    Zde je ukázkový PowerShell skript pro dotazování do systémových a aplikačních záznamů událostí na klíčové slovo "memory". Neváhejte použít jiné řetězce jako "zdroj" pro své vyhledávání:

    Get-EventLog System -ComputerName "$env:COMPUTERNAME" -Message "*memory*"
Get-EventLog Application -ComputerName "$env:COMPUTERNAME" -Message "*memory*"

  • Řešit případné problémy s kódem nebo konfigurací u méně kritických aplikací nebo služeb, aby se snížila jejich spotřeba paměti.

  • Pokud aplikace kromě SQL Server spotřebovávají zdroje, zkuste tyto aplikace zastavit nebo přeplánovat, případně zvažte jejich spuštění na samostatném serveru. Tyto kroky odstraní tlak na externí paměť.

Tlak na vnitřní paměť, který nepochází ze SQL Server: diagnostika a řešení

Pro diagnostiku vnitřního tlaku na paměť způsobeného moduly (DLL) uvnitř SQL Server použijte následující přístup:

  • Pokud SQL Server nepoužívá možnost Zamknout stránky v paměti (AWE API), většina jeho paměti se odráží v čítačiSQLServr (instance) Process:Private Bytes v Sledování výkonu. Celkové využití paměti přímo v SQL Server enginu se odráží v počítadle SQL Server:Memory Manager: Total Server Memory (KB). Pokud najdete významný rozdíl mezi hodnotou Process:Private Bytes a SQL Server:Memory Manager: Total Server Memory (KB), pak tento rozdíl pravděpodobně pochází z DLL (linked server, XP, SQLCLR atd.). Například pokud je Private Bytes 300 GB a celková serverová paměť 250 GB, pak přibližně 50 GB celkové paměti v procesu pochází z vnějšího SQL Server enginu.

  • Pokud SQL Server používá Lock pages in memory (AWE API), je obtížnější problém identifikovat, protože Performance Monitor nenabízí AWE čítače sledující využití paměti pro jednotlivé procesy. Celkové využití paměti přímo v SQL Server enginu se odráží v počítadle SQL Server:Memory Manager: Total Server Memory (KB). Typické hodnoty Process:Private Bytes se mohou pohybovat mezi 300 MB a 1–2 GB celkem. Pokud zjistíte, že Process:Private Bytes je nad rámec běžného použití významnější, pak rozdíl pravděpodobně pochází z DLL (propojený server, XP, SQLCLR atd.). Například pokud je počítadlo soukromých bajtů 5–4 GB a SQL Server používá zámkové stránky v paměti (AWE), pak velká část soukromých bajtů může pocházet z vnějšího SQL Server enginu. Jedná se o aproximační techniku.

  • Použijte nástroj Tasklist k identifikaci všech DLL, které jsou načteny v prostoru SQL Server:

    tasklist /M /FI "IMAGENAME eq sqlservr.exe"

  • Tento dotaz můžete také použít k prozkoumání načtených modulů (DLL) a zjistit, jestli se něco neočekává

    SELECT * FROM sys.dm_os_loaded_modules

  • Pokud máte podezření, že modul propojeného serveru způsobuje značnou spotřebu paměti, můžete ho nastavit tak, aby se vyčerpal proces, vypnutím možnosti Povolit průběh (Povolit průběh). Pro více informací viz Vytvořit propojené servery (Databázový stroj systému SQL Server). Ne všichni poskytovatelé OLEDB propojených serverů se vyčerpají; Pro více informací kontaktujte výrobce produktu.

  • V ojedinělých případech, kdy jsou použity OLE automatizační objekty (sp_OA*), můžete objekt nastavit tak, aby běžel v procesu mimo SQL Server nastavením kontextu = 4 (pouze lokální (.exe) OLE server). Pro více informací viz sp_OACreate.

Využití interní paměti SQL Server enginem: diagnostika a řešení

  • Začněte sbírat čítače monitorů výkonu pro SQL Server:SQL Server:Buffer Manager, SQL Server: Memory Manager.

  • Dotazujte se na DMV pro správce paměti SQL Server vícekrát, abyste zjistili, kde se uvnitř enginu vyskytuje nejvyšší spotřeba pamětí:

    SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC

  • Alternativně můžete sledovat podrobnější výstup DBCC MEMORYSTATUS a způsob, jakým se mění, když vidíte tyto chybové zprávy.

    DBCC MEMORYSTATUS

  • Pokud identifikujete jasného viníka mezi paměťovými úředníky, zaměřte se na konkrétní spotřebu paměti pro danou složku. Zde je několik příkladů:

    • Pokud MEMORYCLERK_SQLQERESERVATIONS paměťový úředník spotřebovává paměť, identifikujte dotazy, které využívají obrovské paměťové granty, a optimalizujte je pomocí indexů, přepište je (například odstraňte ORDER by) nebo aplikujte dotazovací hint.
    • Pokud je uloženo velké množství ad hoc plánů dotazů, pak CACHESTORE_SQLCP paměťový úředník využívá velké množství paměti. Identifikujte neparametrizované dotazy, jejichž dotazovací plány nelze znovu použít, a parametrizujte je buď převodem na uložené procedury, použitím sp_executesql, nebo použitím FORCED parametrizace.
    • Pokud objektový plán cache store CACHESTORE_OBJCP spotřebovává mnoho paměti, udělejte následující: identifikujte, které uložené procedury, funkce nebo triggery využívají hodně paměti, a případně aplikaci přepracujte. Často se to stává kvůli velkému množství databází nebo schémat se stovkami procedur v každé.
    • Pokud OBJECTSTORE_LOCK_MANAGER paměťový úředník zobrazuje velké alokace paměti, identifikujte dotazy, které aplikují mnoho zámků, a optimalizujte je pomocí indexů. Zkracujte transakce, které způsobují, že zámky nejsou dlouho uvolněny v určitých úrovních izolace, nebo zkontrolujte, zda je eskalace zámků zakázána.

Rychlá úleva, která možná zpřístupní vzpomínky

Následující akce mohou uvolnit část paměti a zpřístupnit ji SQL Server:

  • Zkontrolujte následující konfigurační parametry paměti SQL Server a zvažte zvýšení maximální úrovně paměti serveru, pokud je to možné:

    • Max serverová paměť

    • min serverová paměť

      Všimněte si neobvyklých nastavení. Opravte je podle potřeby. Zohledněte zvýšené nároky na paměť. Výchozí nastavení jsou uvedena v možnostech konfigurace serverové paměti.

  • Pokud jste ještě nenastavili maximální paměť serveru , zejména s Lock pages in memory, zvažte nastavení na určitou hodnotu, abyste umožnili nějakou paměť pro operační systém. Viz možnost Zamknout stránky v konfiguraci paměťového serveru.

  • Zkontrolujte zátěž dotazů: počet současných relací, aktuálně spouštěné dotazy a zjistěte, zda existují méně kritické aplikace, které lze dočasně zastavit nebo přesunout na jiný SQL Server.

  • Pokud spouštíte SQL Server na virtuálním stroji (VM), ujistěte se, že paměť pro VM není přetížená. Tipy, jak nastavit paměť pro VM, najdete v tomto blogu Virtualization – Overcommitting memory and how to detect within the VM a Troubleshooting problems performance es ESX/ESXi virtual machine (memory overcommitment)

  • Můžete spustit následující DBCC příkazy a uvolnit několik SQL Server cache paměťových úseků.

    • DBCC FREESYSTEMCACHE

    • DBCC FREESESSIONCACHE

    • DBCC FREEPROCCACHE

  • Pokud používáte Resource Governor, doporučujeme zkontrolovat nastavení resource poolu nebo skupiny pracovních zátěží a zjistit, zda neomezují paměť příliš výrazně.

  • Pokud problém přetrvává, budete muset dále prozkoumat a případně zvýšit zdroje serveru (RAM).

  • Last updated on