 4 | . Have you set the database page size to 256KB? The maximum supported page size is 64KB, but unfortunately ... there will be a clear limit of 64KB. Thank you for this report. To avoid this error use page size of 64KB or ... page size? For my use case, this would make 4 less disk accesses in the Amazon AWS EC2 provisioned |
3 | . the total size of database pages that have to be replaced) is limited by the JVM heap size. Supporting ... that can address your needs. Particularly the unlimited size. The memory problem is with Page ... to support unlimited number of Page instances. Regarding a new maximum for transaction size. In the long term |
3 | thread dump shows a page cache lock (0x00000000b6681e10) by one thread. The second thread dump ... " resize="256kb" page="2kb" />
|
3 | SELECT count(e) FROM Meta e, ImageNet i, Page p
WHERE e.idImage=i.id AND e.idPage=p.id; So simple ... recommended when using JPA. It seems that a Meta instance holds the IDS of an Image and a Page instances ... ) FROM Meta e, ImageNet i, Page p
WHERE e.image=i AND e.page=p Anyway, this still doesn't justify |
2 | ] cl.intelidata.jpaodb.Movil
- Unexpected object count: 142351618 (actual 142351616)
Page Relation Errors
--------------------
[1] Page #36099460 unexpected exception: null
[2] Page #36099460 last key is null, parent page #43650945 next key is ('3.203.10.00.100000','95798112',2421822
8)
[3 |
2 | .ObjectProperty - Unexpected object count: 49830620 (actual 49830619) Page Content Errors ------------------- [1] Page #16748245 has a non first section entry (at entry 1). Index Errors ------------ [1 ... : Page#7880349 5:194359909 0/2 0+1954/2699 ... The main error message may possibly reflect |
2 | caching 1 MB (4 256KB sized pages). The goal is to have frequent PersistenceManager L1 cache hit ... mentioned above) appropriate to achieve this goal? Having larger database pages may have other effects (e.g. searching for an object in a larger page could take longer). So, as with most tuning questions |
2 | in memory was quite a challenge even with 3GB heap space. So I did paging using two loops.
for (int page=0; page < resultCount; page+=pageSize) {
Query q = em.createQuery("query");
for (Tuple t : q.setFirstResult(page).setMaxResults(pageSize).getResultList()) {
// work |
2 | splits large objects (> 2000 bytes) into pages. Somehow the stack trace indicates an unexpected state in which the same object is marked as small in one page and as large in another page. Maybe ... : 3691044274576634723 (expected 1378) [5] Unexpected total page count: 8719319783396618851 (expected 2816 |
2 | on the server side became higher mainly due to increasing page cache size. I see that the test uses 4 different databases (2 large and 2 small). The default size of each page cache (per database) is 64MB ... (page caches of the 2 other databases, query results caches, etc.) consume additional memory |
