We are trying to save 4.5M (150Mb) of keys and the GEODE server already eats ~3.5Gb of RAM , any idea how we can offload less recently used to the disc.
<region name="test">
<region-attributes data-policy="replicate" scope="distributed-ack">
<eviction-attributes>
<lru-memory-size action="overflow-to-disk" maximum="100"/>
</eviction-attributes>
</region-attributes>
</region>
Have you followed the "Configuring Data Eviction" docs and had problems ?
Related
The problem
We're facing the UT000047: The number of parameters exceeded the maximum of 1000 issue.
(We use WilfdFly 16).
What we tried, and worked, but is not acceptable
We followed the solution in UT000047, i.e. increase the max-parameters of the http-listener in the "standalone.xml" file:
<subsystem xmlns="urn:jboss:domain:undertow:8.0">
<server name="default-server">
<http-listener name="default" ... max-parameters="2000" />
This works: no UT000047 any more.
But this solution is rejected by our organization (since it implies to modify all the WF services of our organization, just to make 1 page of 1 application works).
What we'd prefer
We would prefer to increase the max-parameter attribute only for this application (even better: only for the HTML page).
We know that some application-specific configuration can be made through a "WEB-INF/jboss-deployment-structure.xml". Such a solution would be fine for us. But (AFAIK) the max-parameter cannot be defined in this file.
Product name: Open Liberty
Product version: 20.0.0.7
Product edition: Open
is it possible to implement persistent ejbtimers on filesystem based default derby DB, using embedded.derby.DB
I installed derby in /tmp/derby, configured server.xml with the following, i don't see any file being created under /tmp when I start the OpenLiberty JVM, what am I missing in this approach?
<feature>ejbPersistentTimer-3.2</feature>
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDerbyDatasource" jndiName="jdbc/defaultDatasource" statementCacheSize="10" transactional="false">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
Check this book - http://www.redbooks.ibm.com/abstracts/sg248076.html?Open
In chapter "5.2.4 Developing applications using timers" you should find all stuff needed.
UPDATE based on comment:
If you look to the book and to the log it shows:
[INFO ] CNTR4000I: The ITSOTimerApp.war EJB module in the ITSOTimerApp
application is starting.
[INFO ] CNTR0167I: The server is binding the com.ibm.itso.timers.TimerBean
interface of the TimerBean enterprise bean in the ITSOTimerApp.war module of
the ITSOTimerApp application. The binding location is:
java:global/ITSOTimerApp/TimerBean!com.ibm.itso.timers.TimerBean
[INFO ] DSRA8203I: Database product name : Apache Derby
[INFO ] DSRA8204I: Database product version : 10.8.2.3 - (1212722)
[INFO ] DSRA8205I: JDBC driver name : Apache Derby Embedded JDBC Driver
[INFO ] DSRA8206I: JDBC driver version : 10.8.2.3 - (1212722)
[INFO ] CNTR0219I: The server created 1 persistent automatic timer or timers
and 0 non-persistent automatic timer or timers for the ITSOTimerApp.war module.
TimerBean initialized
It creates db 'as needed' so if you dont have any persistent timers beans, the service will not be started nor db created.
Liberty in general follows lazy model and doesn't start unneeded services.
So create sample application and then your DB will be created. There is no need to create database nor connection to database when no one is requesting for it.
In general, it is not advisable to use Derby Embedded database for persistent EJB timers due to limitations of Derby Embedded that all connections use the same class loader (implying the same JVM as well). This means you cannot leverage the failover capability (missedTaskThreshold setting) or even have multiple servers connected to the database at all. If you decide to use a Derby Embedded database, it means that you are limiting yourself to a single server. You can decide for yourself if that is acceptable based on what your needs are.
In the case of the example configuration you gave, it doesn't work because the EJB persistent timers feature in Liberty has no way of knowing that you dataSource, "DefaultDerbyDatasource" with jndiName "jdbc/defaultDatasource" is the data source that it ought to use. Also, it is incorrect to specify transactional="false" on the data source that you want EJB persistent timers to use because EJB persistent timers are transactional in nature.
I assume that what you are intending to do is configure the Java EE default data source and expecting EJB persistent timers to use it. That approach will work, except that you'll need to configure the Java EE default data source, you need to specify the id as "DefaultDataSource".
Here is an example that switches your configured data source to the Java EE default data source and removes the transactional="false" config,
<library id="DerbyLib">
<fileset dir="/tmp/derby/lib" includes="derby.jar"/>
</library>
<dataSource id="DefaultDataSource" jndiName="jdbc/defaultDatasource" statementCacheSize="10">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded createDatabase="create" databaseName="/tmp/sample.ejbtimer.db" shutdownDatabase="false"/>
<containerAuthData user="user1" password="derbyuser" />
</dataSource>
By default, the EJB persistent timers feature should create database tables once the application runs and the EJB module is used.
However, you may be able to verify the configuration prior to that point by running the ddlgen utility (after correcting the configuration as above)
https://www.ibm.com/docs/en/was-liberty/base?topic=line-running-ddlgen-utility
which gives you the opportunity to see the DDL that it will use and optionally to run it manually (which is useful if you turned off automatic table creation via
<databaseStore id="defaultDatabaseStore" createTables="false"/> )
We are running on 32bit windows and since upgrading from 1.4.1 to 2.2.2, we are seeing the following memory in stdout (numbers not exact):
INFO: Database 'BLAH' uses 770MB/912MB of DISKCACHE memory, while Heap is not completely used (usedHeap=123MB maxHeap=512MB). To improve performance set maxHeap to 124MB and DISKCACHE to 1296MB
With 32bit, we can only set a max of Xmx + storage.diskCache.bufferSize ~= 1.4gb without getting OOM or performance issues. Any combination of different sizes of either of these two configurable variables results in a variant of the above message.
Is there a way to suppress the above profiler/memory checker messages?
You can disable the profiler with:
java ... -Dprofiler.enabled=false ...
Set that configuration in your server.sh or in the last section of config/orientdb-server-config.xml file.
My system run out of memory sometimes. I can see bellow error in logs every time when system is running out of heap memory
Maximum number of threads (200) created for connector with address abc.com/192.168.1.45 and port 8080
Any ideas why this is happening?
JBoss is crashing due to a high number of threads created. When it tries to create a new one, the application stops responding and starts to shutdown the application server.
Increasing the maxThreads parameter will resolve the issue. Do this incrementally; raising the value of maxThreads too much can result in performance problems such as:
High memory usage
General slowness due to the JVM being forced to context switch
between many threads frequently
To increase maxThreads edit in JBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy/jbossweb.sar/server.xml
<!-- A HTTP/1.1 Connector on port 8080 -->
<Connector protocol="HTTP/1.1" port="8080" address="${jboss.bind.address}"
connectionTimeout="20000" redirectPort="8443" maxThreads="3000"
minSpareThreads="2000" maxKeepAliveRequests="-1" />
see also: Performance Tuning Guide - Chapter 2. Connectors
I am executing below C# code -
for (; ; )
{
Console.WriteLine("Doc# {0}", ctr++);
BsonDocument log = new BsonDocument();
log["type"] = "auth";
BsonDateTime time = new BsonDateTime(DateTime.Now);
log["when"] = time;
log["user"] = "staticString";
BsonBoolean bol = BsonBoolean.False;
log["res"] = bol;
coll.Insert(log);
}
When I run it on a MongoDB instance (version 2.0.2) running on virtual 64 bit Linux machine with just 512 MB ram, I get about 5k inserts with 1-2 faults as reported by mongostat after few mins.
When same code is run against a MongoDB instance (version 2.0.2) running on a physical Windows machine with 8 GB of ram, I get 2.5k inserts with about 80 faults as reported by mongostat after few mins.
Why more faults are occurring on Windows? I can see following message in logs-
[DataFileSync] FlushViewOfFile failed 33 file
Journaling is disable on both instances
Also, is 5k insert on a virtual machine with 1-2 faults a good enough speed? or should I be expecting better inserts?
Looks like this is a known issue - https://jira.mongodb.org/browse/SERVER-1163
page fault counter on Windows is in fact the total page faults which include both hard and soft page fault.
Process : Page Faults/sec. This is an indication of the number of page faults that
occurred due to requests from this particular process. Excessive page faults from a
particular process are an indication usually of bad coding practices. Either the
functions and DLLs are not organized correctly, or the data set that the application
is using is being called in a less than efficient manner.