"The buffer pool is too full to bring in another page" running two instances of updall with server down

This may be the same issue reported in SPR #JCHN5E4UGB and fixed in 6.0.1CF2, but we’re running 6.5.1, and the server didn’t have a lot of balls in the air at the time. When I saw the error [06/20/2004 08:18:33 AM Error updating view ‘2. By Team Member’ in f:\notes\data\abc\def\xxxxxxx.NSF: The buffer pool is too full to bring in another page. ], I had shut down Domino, and was running just two instances of updall -C from separate command prompts to build the views in a pair of large (1-2GB) DBs whose view indexes I had previously dropped by running compact -d.

Any thoughts? It’s a little surprising that just two single-instance indexers running concurrently could consume all of a Domino memory pool, but if that’s the case, how do I determine which pool it is, and can I increase the size of that pool? Setting dirman_poolsize_mb=100 and starting over (as recommended in the 6.0.1 issue) didn’t delay the onset of the error by much, if any.

Subject: “The buffer pool is too full to bring in another page” running two instances of updall with server down

Hi Ted,

I’m not quite sure your problem is the same as in SPR #JCHN5E4UGB.

This SPR reffers to AIX as OS (this configuration resides in /etc/system file).

You say you are using Win2K, so this parameter is not correct, and is not a notes.ini option, so it appears to be unused. Try to change default path to TEMP index files. Besides, if you have a 2Gb Db with a lot of views, I propose to use “updall -C” only once.

Let us know if the problem was solved.

Regards,

Daniel

Subject: tell me more, please!

Thanks, Daniel – I’m take it you’re with IBM, since the public SPR description I can see doesn’t come close to your level of detail (and says the issue is cross-platform, to boot). Our issue is likely not the same problem as John’s SPR, but that was the only mention I found of the error.

A couple of questions, since you’re way ahead of me on this one:

  1. What happens to the view index whose update is interrupted by this error? Is it still usable, or does it contain incomplete information? The error message is only listed as a Warning (Low) in events4.nsf; I hope that means it’s nothing more than a nuisance error message, and that the update is completed after some delay. Thanks for any detail you can provide.

  2. The database is large (closer to 6 GB than 2, once all views are built), but each instance of updall (even with -C) seems to touch just one view at a time. What does updall do that the regular indexer doesn’t that lets updall exhaust the buffer pool with just two instances running in the same partition…or would Update have the same trouble if I had two instances running on Domino, and they happened to open these two databases at the same time? Concern for Domino’s internal limits was one of the factors that led me to stop the server and run updall standalone in the first place. We have view_rebuild_dir pointing to a subdirectory on a drive with lots of free space, FWIW. If free space in the view temp folder isn’t the key, what’s the magic characteristic?

Thanks again!

Ted

Subject: RE: tell me more, please!

Hi Ted,

I don’t know if I can add too much information.

Let me try to help as much as I can.

  1. In normal case the view index which is being indexed when update stop, will be corrupted. I don’t believe you will have any error message in the log or events Db. But if you query the view you will probably get inconsistent responses to your query.

  2. The problem is not connected to the 2 instances running in the same time, but with large number of views in a large database. I’m not quite sure the limitation comes from the domino side, but can be also connected to what the OS can give. I have a server with a “small” mail file of around 6.5Gb, and a lot of folders inside, running on AS400 (a small 270 machine), and updall runs there with small delays, nothing serious. This mail Db is being maintened for a very long time and the server is up for more than 3 months this days.

I don’t know how can I help you more, but if you was using an AS400 or Unix machine, I will give a shot in files descriptors, or buffers for I/O. The problem seems to be there someway…

What you can try (but again I don’t know if windows can do this…) is use different hard drives for domino data, and view_rebuild_dir, and if it’s possible different SCSI controllers.

Let us know if you have success with that…

Regards,

Daniel

n.b.: I’m not IBM… I just have replicas of knowledge base and other Db’s as a business partner. Besides my job is help my custommers with problems they have, each one using different configurations, OS and systems…

Subject: Thank you, Daniel