I am using JPOS transaction manager for developement. I want to know the exact default space size in JPOS.How to increase it.what should i do for increasing it.
Related
I've noticed that the file size doesn't increase each time I've written a dataset into the DB. Instead it increases only once in a while by some amount. Is it some constant or percentage based rule? When does the file size increase? Does the file size increase more at once if the DB size or the file size is bigger?
I'm using an embedded H2 version 1.4.197 with MV store and encryption.
Our application shows frequent Full GCs after load of about 24 hours. Forcing restarts.
When we analyzed our GC logs, it indicated that the out of 20GB MaxHeap, only 1GB was used for young generation and the 19GB was used by OLD generations.
Command options were -Xms2g -Xmx20g
Should the -Xms2g be bumped to 10GB or make equal to 20GB so that the NewRatio default ratio of 2 can let the young generation use larger portion of the JVM?
Monitored the JVM Heap using jmap -histo and found a pattern when it gives spike in the heap size.
Also tried the GC log analysis using http://gceasy.io
Actually some hibernate entities were getting piled up in the transaction which was an issue in the code.
Got it corrected in the code and it does help keeping the heap under control and not spike it.
On another note, it was observed that though the New-Old ratio was not specified, so the JVM should have used 1:2 ration, but it was not the case.
Hence specifically provided values for NewSize and MaxNewSize and it helped getting better results.
I have a bunch of rows on HBase which store varying sizes of data (0.5 MB to 120 MB). When the scanner cache is set to say 100, the response sometimes gets too large and the region server dies. I tried but couldn't find a solution. Can someone help me finding
What is the maximum response size that HBase supports?
Is there a way to limit the response size at the server so that the result will be limited to a particular value (answer to the first question) so that the result will be returned as soon as the limit is reached?
What happens if a single record exceeds this limit? There should be a way to increase it but I don't know how.
1. What is the maximum response size that HBase supports?
It is Long.MAX_VALUE and represented by the constant DEFAULT_HBASE_CLIENT_SCANNER_MAX_RESULT_SIZE
public static long DEFAULT_HBASE_CLIENT_SCANNER_MAX_RESULT_SIZE = Long.MAX_VALUE;
2. Is there a way to limit the response size at the server so that the result will be limited to a particular value (answer to the first question) so that the result will be returned as soon as the limit is reached?
You could make use of the property hbase.client.scanner.max.result.size to handle this. It allows us to set a maximum size rather than count of rows on what a scanner gets in one go. It is actually the maximum number of bytes returned when calling a scanner's next method.
3. What happens if a single record exceeds this limit? There should be a way to increase it but I don't know how.
Complete record(row) will be returned even if it exceeds the limit.
Transactional log file system(/var/mqm/log) become full and i am getting MQRC 2102 resource problem with Queue Manager while attempting client connection to this queue manager. What course of action we can do to resolve this?
LogPrimaryFiles=2
LogSecondaryFiles=8
LogFilePages=16384
LogType=CIRCULAR
LogBufferPages=0
LogPath=/var/mqm/log/QMGRA/
LogWriteIntegrity=TripleWrite
Is adding additional disk space to /var/mqm/log is the only solution?
I have few queues that were full,but queue storage file system were only 60% used.
Please give me some ideas on this.
Log file pages are 4096 bytes each so a setting of LogFilePages=16384 results in log files extents of 64MB each. With a setting of LogPrimaryFiles=2 and LogSecondaryFiles=8 there can be up to 10 log files for a total of 640MB. If the file system that the circular logs resides on is less than this amount, it may fill up.
The optimum solution here is to increase the size of the log file disk allocation to something a little larger than the log file extents require. If that is not possible or you need a temporary fix then it is necessary to change the size of the log file requirement by reducing the number of extents and restarting the QMgr. Note that you can adjust the number of log extents but not the size of the extents. If it becomes necessary to change the LogFilePages=16384 parameter then it is necessary to rebuild the QMgr.
The number and size of of extents represents the total amount of data that can be under syncpoint at once but 640MB is generous in most cases. In terms of time, it also limits the longest possible duration of a unit of work on an active QMgr. This is because an outstanding transaction will be rolled back if it happens that the head pointer in the log file ever overtakes the tail pointer. For example, suppose a channel goes into retry. This holds a batch of messages under syncpoint and holds that log extent active. As applications and other channels perform their normal operations, additional transactions drive the head pointer forward. Eventually all extents will be used, and although there may be very few outstanding transactions the oldest one will be rolled back to free up that extent and advance the tail pointer forward. If the error log shows many transactions are rolled back to free log space then you really would need to allocate more space to the log file partition and bump the number of extents.
The currently released versions of Ehcache (2.4.1 is the latest) only support settings to control the maximum number of elements in the cache (maxElementsInMemory, and maxElementsOnDisk). How do you determine what the optimal value is for these two settings?
For example, if I know my maximum heap size is set to 250m, how do I decide what the best value is for maxElementsInMemory?
Actually you can count that size approximately depending on the size of the entities your are going to put inside the cache but practice shows that that's more like how many entities your application is going to use and depends on the load, complexity and concurrent sessions (or simply concurrent users) your app has. Just simply speaking try playing with numbers, start around 1000 objects and see the memory usage of your app, if it won't go up then it's ok if it's around 500mb the you should target max elements size depending on this value