CreateFileMapping failed with OS status 1816 (Not enough quota is available to process this command)
in [Win32 Kernel]
|
Prev: ETW End-To-End Tracing
Next: CreateFileMapping failed with OS status 1816 (Not enough quotais available to process this command)
From: Christoph Rupp on 30 Mar 2010 11:07 Hi, I have a database library which uses memory mapped I/O to read pages (usually 64k) from the database file. If this file becomes huge, then i get above error on Win XP 32bit. I did some research about this and wanted to check with you what i found out. Also, i have some ideas for solutions and want to verify what is feasible. Here's a screenshot of my application in the task manager. (highlighted in blue) http://crupp.de/taskmanager.png From what i discovered, i'm hitting some wall regarding either paged or non-paged memory. I guess it's the non-paged, although the limits are quite low (450k). Am i right with that guess? My preferred solution (rather a workaround) for that problem is that i can somehow query the amount of available pool memory and then try not to exceed it (= set my internal caching limits). But i have not found a SDK function which gives me this setting. Is there such a function? I also discovered that i can change registry settings (or maybe even boot.ini?) to avoid that problem, but that's not an acceptable workaround for most of my users. Another solution would be to fall back to ReadFile()/WriteFile() when i hit this error. Opinions are very welcome. Thanks a lot Christoph
From: Christoph Rupp on 31 Mar 2010 01:36 Hi Stefan, On Mar 30, 6:58 pm, Stefan Kuhr <kustt...(a)gmx.li> wrote: > The amount of kernel object handles looks suspicious to me. Do you have > a handle leak? What kind of handles are these? NP memory usage for this > process looks high as well. No handle leak... when i get the error message, my file size is grown to 732 MB. A page is 64kb. That means i have about 11500 pages, both with a handle for the file mapping (CreateFileMapping) and the view (MapViewOfFile). (in this scenario, all pages are cached and never unmapped before the application terminates.) I think that maybe the file mapping handles are not counted as handles, or they're reused internally. otherwise the handle count would be twice as high. I agree that it's a lot of handles (~ 11600), but it's not THAT much - i've seen (leaky) processes on the same machine consuming more than 50000. That's why i also think that NP pool is exhausted, but i don't know how i can really verify that it's the NP pool, and i would like to find out how to get the NP Pool size in order to limit my caching. Bye Christoph > > -- > S
From: Alexander Grigoriev on 31 Mar 2010 10:25 Fix your handle leak, then see if you're still getting problems. "Christoph Rupp" <cruppstahl(a)gmail.com> wrote in message news:271e7fd6-8766-44f1-b23c-b0e770de0e3a(a)33g2000yqj.googlegroups.com... Hi Stefan, On Mar 30, 6:58 pm, Stefan Kuhr <kustt...(a)gmx.li> wrote: > The amount of kernel object handles looks suspicious to me. Do you have > a handle leak? What kind of handles are these? NP memory usage for this > process looks high as well. No handle leak... when i get the error message, my file size is grown to 732 MB. A page is 64kb. That means i have about 11500 pages, both with a handle for the file mapping (CreateFileMapping) and the view (MapViewOfFile). (in this scenario, all pages are cached and never unmapped before the application terminates.) I think that maybe the file mapping handles are not counted as handles, or they're reused internally. otherwise the handle count would be twice as high. I agree that it's a lot of handles (~ 11600), but it's not THAT much - i've seen (leaky) processes on the same machine consuming more than 50000. That's why i also think that NP pool is exhausted, but i don't know how i can really verify that it's the NP pool, and i would like to find out how to get the NP Pool size in order to limit my caching. Bye Christoph > > -- > S
From: m on 31 Mar 2010 18:25
First, a page is not 64 KB on any system that I have seen - this is the usual allocation granularity though. Second, allocating pages does not consume handles - Virtual Address Descriptors (VADs) yes, and if you map them one page at a time it will take extra. The short answer is that in 32-bit XP, you cannot allocate this many system resources - hence your error. And also you likely have either a handle leak or a very bad allocation pattern; either should be fixed. "Christoph Rupp" <cruppstahl(a)gmail.com> wrote in message news:271e7fd6-8766-44f1-b23c-b0e770de0e3a(a)33g2000yqj.googlegroups.com... > Hi Stefan, > > On Mar 30, 6:58 pm, Stefan Kuhr <kustt...(a)gmx.li> wrote: >> The amount of kernel object handles looks suspicious to me. Do you have >> a handle leak? What kind of handles are these? NP memory usage for this >> process looks high as well. > > No handle leak... when i get the error message, my file size is grown > to 732 MB. A page is 64kb. That means i have about 11500 pages, both > with a handle for the file mapping (CreateFileMapping) and the view > (MapViewOfFile). (in this scenario, all pages are cached and never > unmapped before the application terminates.) > > I think that maybe the file mapping handles are not counted as > handles, or they're reused internally. otherwise the handle count > would be twice as high. > > I agree that it's a lot of handles (~ 11600), but it's not THAT much - > i've seen (leaky) processes on the same machine consuming more than > 50000. > > That's why i also think that NP pool is exhausted, but i don't know > how i can really verify that it's the NP pool, and i would like to > find out how to get the NP Pool size in order to limit my caching. > > Bye > Christoph > >> >> -- >> S > |