I would like to know if the parameter maximumPoolSize on service WorkManagerThreadPool in jca-boss-beans.xml limit the maximum of threads we can instantiate ?
Thanks for your answers,
Nicolas Maujean
It's the maximum number of JCA connections that can be active at the same time (each connection is managed by a thread). So this property doesn't limit the overall number of threads JBoss is using, but just JCA connections. If you want more information about performance and pools you can check Best Practices for Performance Tunning.
Related
Yet I can not find any reliable recommendation regarding the optimal value for max_worker_processes.
Some sources suppose that the value should not be higher than the number of available cores, but is that correct taking that server threads do a lot of IO?
Say I have 8 cores for PG container and plan to handle about 100 clients in parallel. Is that feasible, especially with the default max_worker_processes=8 ?
Any trusted reference would be much appreciated.
The reasonable limit dies not depend on the number of client connections, but on the actual upper limit on concurrent queries.
If it is guaranteed that only one of these clients will ever be active at the same time, you could set max_worker_processes, max_parallel_workers and max_parallel_workers_per_gather one less than the number of cores or parallel I/O operations that your storage can handle, whatever of the two is smaller. In essence, one query can then consume all the available resources.
On the other hand, if many of these clients are likely to run queries concurrently, you should disable parallel query by setting max_parallel_workers_per_gather to 0 to avoid overloading your database.
Concerning your comments to my answer: if your goal is to limit the number of active queries, use a connection pool.
In our WSO2 setup, whenever the APIm comes up, it creates close to 50+ DB connections towards the PostGres DB. In stable phase, each APIm instance has only 4 DB connections. I would like to understand why it needs 50+ connections at startup? is it a bug or by design?
We run WSO2 in kubernetes setup, PostGres has a max connection limit set to 100, and two instances of APIm is not able to come-up due to this issue.
Within the WSO2 platform, the Tomcat JDBC pooling is used as the default pooling framework due to its production-ready stability and high performance. The goal of tuning the pool properties is to maintain a pool that is large enough to handle peak load without unnecessarily utilizing resources. These pooling configurations can be tuned for your production server in general in the <PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml file. This is applicable if you are using an APIM version less than or equal to 2.6. If you are using APIM-3.X.X then these configurations can be found in <PRODUCT_HOME>/repository/conf/deployment.toml file.
The following parameters should be considered when tuning the connection pool:
The application's concurrency requirement.
The average time used for running a database query.
The maximum number of connections the database server can support.
The maxActive value is the maximum number of active connections that can be allocated from the connection pool at the same time. The default value is 100. The maximum latency (approximately) = (P / M) * T, where,
M = maxActive value
P = Peak concurrency value
T = Time (average) taken to process a query
Therefore, by increasing the maxActive value (up to the expected highest number of concurrency), the time that requests wait in the queue for a connection to be released will decrease. But before increasing the Max. Active value, consult the database administrator, as it will create up to maxActive connections from a single node during peak times, and it may not be possible for the DBMS to handle the accumulated count of these active connections.
Note that this value should not exceed the maximum number of requests allowed for your database.
For more details on this topic please refer to the official documents[1, 2].
[1] https://docs.wso2.com/display/ADMIN44x/Performance+Tuning#PerformanceTuning-JDBCpoolconfiguration
[2] http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
can somebody please explain me what is the cause of this error:
You have reached maximum pool size for given partition
In latest 2.1.x version, you do not have this exception any more.
You merely wait till new connection will be available.
But I will explain it any way. To increase multiprocessor scalability pool is split on partitions and several threads work together on single partition.
Each partition has queue , when limit if connections for this queue is reached exception is thrown. But again it is already not the case for latest version.
So the best approach to fix this issue is to upgrade to latest version and set limit of maximum connections. Would be cool if you will add more information in your question , but I suppose that you use OrientGraphFactory which in latest version has maximum limit of connections equals to number of CPU cores.
Like the title days: does the maximum number of requests JBoss AS can serve per second depend on the OS configuration (number of connections, threads, etc.), or are there some theoretical limits in the AS self?
I am not talking about setting these limits myself, with JBoss parameters like maxThreads, but about limitations that cannot be overcome by tweaking and optimizing the AS.
I am not sure what type of request you are talking about. I will assume HTTP requests. If so then the max number of requests or threads is calculated as (32 times the number of processors available to the Java virtual machine.)
If it is another type of request, please clarify.
I have read that you should keep the number of connections in your database connection pool lower than the number of threads running in the application server and that might use that pool correct?
I have read too that having a high number of connections is not good but I don't really know why? Would it use more memory?
Right now during pick times my server is running out of connections and I don't know it would be good just to increase the number of connections.
Thank you
With a Small Connection pool you have faster access on the connection table but may not have enough connections to satisfy requests.
In the other hand with a Large Connection pool there are more connections to fulfill requests and requests will spend less (or no) time in the queue but access on the connection table is slower.
http://docs.oracle.com/cd/E19316-01/820-4343/abehs/index.html
core_count = 4
connections = ((core_count * 2) + effective_spindle_count) = 9