我有一個使用SQL FILESTREAM存儲圖像的應用程序。我插入圖像的LOT（每天幾百萬張圖像）。使用SQL FileStream的內存泄漏
一段時間後，機器會停止響應，似乎內存不足......綜觀PC的內存使用情況，我們沒有看到任何進程採取了大量的內存（沒有SQL或我們的應用程序） 。我們試圖殺死我們的進程，但它並沒有恢復我們的機器......然後我們終止了SQL服務，並且它沒有恢復到系統。作爲最後的手段，我們甚至殺死了所有進程（系統除外），內存仍然很高（我們正在查看任務管理器的性能選項卡）。在這一點上，只有重啓才能完成這項工作。我們已經在Win7，WinXP，Win2K3服務器上嘗試過，總是有相同的結果。
不幸的是，這不是一錘子買賣，它發生的每一次。
以前有人見過這種行爲嗎？我們是否在使用SQL FILESTREAMS做錯了什麼？
你說你每天插入很多圖像。你還對圖像做了什麼？你有更新他們嗎？
是您的文件系統，文件流優化？
如何讀出圖像？
如果你做了很多更新，請記住，SQL Server將不會被垃圾收集器修改文件流對象，而是創建一個新的，並標記爲老刪除。在某個時候，GC會觸發並開始清理舊混亂。 FILESTREAM的問題在於它不會記錄很多事務日誌，因此GC可能會嚴重延遲。如果這是問題，可以通過更頻繁地強制GC來保持響應能力來解決。這可以使用CHECKPOINT聲明完成。
更新：對於小文件（小於1 MB），您不應該使用FILESTREAM。數百萬個小文件會導致文件系統和主文件表出現問題。代替使用varbinary。又見Designing and implementing FILESTREAM storage
更新2：如果你仍然堅持使用存儲在FILESTREAM（你不應該爲大量的小文件），則必須至少配置相應的文件系統。
優化的文件系統大量的小文件（使用這些作爲提示，並確保你瞭解他們在做什麼，然後再應用）
我們能夠通過只做INSERTS，沒有讀取，沒有更新來重現這個問題。 它看起來不像託管內存問題......我們強制垃圾收集器，它並沒有幫助。看起來它可能是操作系統問題，因爲我們的流程記憶看起來不高。 CHECKPOINT語句清除FILESTREAM未引用的文件，所以它不會幫助我們，因爲我們仍然想引用我們的文件... – mdarsigny 2010-01-20 21:08:53
對UPDATE＃1的響應： 我們使用文件流來處理小文件，因爲我們不不想要一個龐大的數據庫文件。我們希望存儲在磁盤上，而不是數據庫...我們知道使用varbinary更高效，但我們不想要一個巨大的DB文件... – mdarsigny 2010-01-20 21:51:28
對UPDATE＃2的響應： 我們已經嘗試你提到的提示。我們注意到它會改善文件插入時間，導致問題發生得更快...... :( 我們懷疑我們創建文件的速度太快，文件系統無法處理（正如您在更新＃1） – mdarsigny 2010-01-20 21:53:55
我的猜測是，它的文件系統或文件句柄。每天有數百萬的圖像是很多的。他們的尺寸是多少？ – 2010-01-20 20:38:58
我們有2種類型的圖像。縮略圖在1kb和2kb之間。 「full-res」略小於50kb。 – mdarsigny 2010-01-20 21:00:31