On 04/23/14 at 01:08pm, Vivek Goyal wrote: > > - bitmap size: used for 1st and 2nd bitmaps > > - remains: can be used for the other works of makedumpfile (e.g. I/O buffer) > > > > pattern | bitmap size | remains > > ----------------------------------------------+---------------+------------- > > A. 100G memory with the too allocation bug | 12.8 MB | 17.2 MB > > B. 100G memory with fixed makedumpfile | 6.4 MB | 23.6 MB > > C. 200G memory with fixed makedumpfile | 12.8 MB | 17.2 MB > > D. 300G memory with fixed makedumpfile | 19.2 MB | 10.8 MB > > E. 400G memory with fixed makedumpfile | 24.0 MB | 6.0 MB > > F. 500G memory with fixed makedumpfile | 24.0 MB | 6.0 MB > > ... > > > > Baoquan got OOM in A pattern and didn't get it in B, so C must also > > fail due to OOM. This is just what I wanted to say. > > ok, So here bitmap size is growing because we have not hit the 80% of > available memory limit yet. But it gets limited at 24MB once we hit > 80% limit. I think that's fine. That's what I was looking for. > > Now key question will remain is that is using 80% of free memory by > bitmaps too much. Are other things happening in system which consume > memory and because memory is not available OOM hits. If that's the > case we probably need to lower the amount of memory allocated to > bit maps. Say 70% or 60% or may be 50%. But this should be data driven. How about add anoter limit, say left memory safety limit, e.g 20M. If the remaining memory which is 20% of free memory is bigger than 20M, 80% can be taken to calculate the bitmap size. If smaller than 20M, we just take (total memory - safety limit) for bitmap size. Thanks Baoquan > >
