I've implemented a web application using GeoServer to provide tile maps. In order to apply caching strategy, I've enabled the embedded GeoWebCache and set tiling page in a PostgreSQL database. The disk quota is set 5 MB and LFU approach to test the truncate behavior on quota limit exceeding. The problem is shown when the caching volumes are more than 5 MB and GeoWebCahe delete all tiles without regarding the "frequency_of_use" of each tile. Is this the expected behavior because I think it should remove least used tiles first.
<!-- geowebcache-diskquota.xml -->
<gwcQuotaConfiguration>
<enabled>true</enabled>
<cacheCleanUpFrequency>10</cacheCleanUpFrequency>
<cacheCleanUpUnits>SECONDS</cacheCleanUpUnits>
<maxConcurrentCleanUps>2</maxConcurrentCleanUps>
<globalExpirationPolicyName>LFU</globalExpirationPolicyName>
<globalQuota>
<value>5</value>
<units>MiB</units>
</globalQuota>
<quotaStore>JDBC</quotaStore>
</gwcQuotaConfiguration>
and the geowebcache-diskquota-jdbc.xml file:
<gwcJdbcConfiguration>
<dialect>PostgreSQL</dialect>
<JNDISource>java:comp/env/jdbc/gwc</JNDISource>
<connectionPool>
<driver>org.postgresql.Driver</driver>
<url>jdbc:postgresql://localhost:5432/gwc</url>
<username>postgres</username>
<password></password>
<minConnections>1</minConnections>
<maxConnections>10</maxConnections>
<connectionTimeout>10000</connectionTimeout>
<maxOpenPreparedStatements>50</maxOpenPreparedStatements>
</connectionPool>
</gwcJdbcConfiguration>
The disk quota mechanism does not track each single tile, but "tile pages", groups of tiles whose statistics are tracked as a unit, in order to reduce the accounting database size.
I don't know the details of the implementation to the point of telling you how big a tile page is, but for a tile cache that is potentially hundreds of gigabytes, I would not be surprised if the minimum tracking unit is more than 5MB. If that's the case, then a delete of all the tiles available in a 5MB quota would be very likely.
Related
I have a PERSISTENT cache configured like this :-
<region name="stock-hist" refid="PARTITION_PERSISTENT" >
<region-attributes disk-store-name="myOverflowStore" disk- synchronous="false">
<partition-attributes local-max-memory="1024" />
<eviction-attributes>
<!-- Overflow to disk when 100 megabytes of data reside in the
region -->
<lru-memory-size maximum="100" action="overflow-to-disk"/>
</eviction-attributes>
</region-attributes>
The problem is that when I storing say 8 GB of data the cache crashes due to too much memory. I do not want that to happen. Like I need the data to overflow to disk when it is beyond 100MB, but get it back to cache if I try to access it. I also want persistent cache.
Also in case I write behind to a database, how can I evict data after sometime.
How does this work?
This is a use-case for which an In-Memory Data Grid is not intended. Based on the problem that you are describing, you should consider using a relational DB OR you should increase memory to use an IN-MEMORY Data Grid. Overflow features are intended as a safety valve and not for "normal" use.
I do not understand when you say that "it" crashes due to "too much" memory since it obviously does not have "enough" memory. I suspect that there is not have sufficient disk space defined. If you think not, check your explicit and not implicit disk allocations.
As for time-based eviction/ expiration, please see "PARTITION_HEAP_LRU" at: http://gemfire.docs.pivotal.io/docs-gemfire/latest/reference/topics/region_shortcuts_reference.html
Using APCu with TYPO3 6.2 extensively, I always get a high fragmentation of the cache over time. I already had values of 99% with a smaller shm_size.
In case you are a TYPO3 admin, I also switched the caches cache_pagesection, cache_hash, cache_pages (currently for testing purposes moved to DB again), cache_rootline, extbase_reflection, extbase_opject as well as some other extension caches to apc backend. Mainly switching the cache_hash away from DB sped up menu rendering times dramatically (https://forge.typo3.org/issues/57953)
1) Does APC fragmentation matter at all or should I simply watch out that it just never runs out of memory?
2) To TYPO3 admins: do you happen to have an idea which tables cause fragmentation most and what bit in the apcu.ini configuration is relevant for usage with TYPO3?
I already tried using apc.stat = 0, apc.user_ttl = 0, apc.ttl = 0 (as in the T3 caching guide http://docs.typo3.org/typo3cms/CoreApiReference/CachingFramework/FrontendsBackends/Index.html#caching-backend-apc) and to increase the shm_size (currently at 512M where normally around 100M would be used). Shm_size does a good job at reducing fragmentation, but I'd rather have a smaller but full cache than a large one unused.
3) To APC(u) admins: could it be that frequently updating cache entries that change in size as well cause most of the fragmentation? Or is there any other misconfiguration that I'm unaware of?
I know there is a lot of entries in cache (mainly JSON data from remote servers) where some of them update every 5 minutes and normally are a different size each time. If that is indeed a cause, how can I avoid it? Btw: APCU Info shows there are a lot of entries taking up only 2kB but each with a fragmented spacing of about 200 Bytes.
4) To TYPO3 and APC admins: apc has a great integration in TYPO3, but for more frequently updating and many small entries, would you advise a different cache backend than apc?
This is no longer relevant for us, I found a different solution reverting back to MySQL cache. Though if anyone comes here via search, this is how we did it in the end:
Leave the APC cache alone and only use it for the preconfigured extbase_object cache. This one is less than 1MB, has only a few inserts at the beginning and yields a very high hit / miss ratio after. As stated in the install tool in the section "Configuration Presets", this is what the cache backend has been designed for.
I discovered this bug https://forge.typo3.org/issues/59587 in the process and reviewed our cache usage again. It resulted in huge cache entries only used for tag-to-ident-mappings. My conclusion is, even after trying out the fixed cache, that APCu is great for storing frequently accessed key-value mappings but yields when a lot of frequently inserted or tagged entries are around (such as cache_hash or cache_pages).
Right now, the MySQL cache tables have a better performance with extended usage of the MySQL server memory cache (but in contrast to APCu with disc backup). This was the magic setup for our my.cnf (found here: http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/):
innodb_buffer_pool_size = 512M
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 8
innodb_flush_method=O_DIRECT
innodb_file_per_table
With this additional MySQL server setup, the default typo3 cache tables do their job best.
I'm using Mapnik to generate map tiles (PNG). I have a url where tiles can be generated on-the-fly individually:
http://tiles.example.com/dynamic/MAPID/ZOOM/X/Y.png
Each map tile is 256x256 pixels.
However, generating tiles individually is expensive. It's much more efficient to generate them batched (i.e. generate one large PNG, and split it into smaller files). I have a URL that can do that too:
http://tiles.example.com/dynamic/MAPID
which batch generates all the tiles for a map and returns "OK" when complete, saves them to disk, from where they are available statically at:
http://tiles.example.com/static/MAPID/ZOOM/X/Y.png
which is NGINX serving raw files.
Is it possible to configure Varnish to trigger a batch generation, wait for it to complete, then cache and serve individual tiles until they expire (in my case, 5 minutes)?
Currently varnish3 doesn't support backend fetching, this feature should be implemented in varnish4, Instead I would suggest to trigger those as cron jobs and varnish would fetch them when the first user hits the image.
I would also recommend that the generation would be done on a separate folder/file location and just move it when they are ready, would spare you the hassle of people hitting your server during the generation.
I need to implement the undo-redo feature in an application, which reads a project file and makes a sequence of separate transactions changing the project's content. The project can be hundreds MB large.
My idea is to implement the undo-redo on the basis of the copy-on-write (PAGE_WRITECOPY) memory mechanism. I assume that after the end of a transaction the application can access both changed and unchanged pages, compare them, identify the changed records, store original record states in the dedicated undo stack, free the created non-changed pages and restore the write-on-copy protection of the changed pages. I have two questions:
How and where I can found the addresses of the original (non-changed) pages.
The awaited performance of such an implementation?. The middle size of the project's records is cira 100 bytes. if a transaction changes 3000 records that may involve the change of 100 or more 4K physical pages. Is the write-on-copy memory performant enough to support the routineous change of the hundreds physical pages on each step?
I am running ATG 9 with a bunch of different objects configured in the repository.xml to have specific cache sizes, ttl etc.
For example:
<item-descriptor name="USER"
query-expire-timeout="300000"
item-expire-timeout="300000"
item-cache-timeout="300000"
item-cache-size="20000"
query-cache-size="50">
...
I am expecting that the cache would not grow above that size and would expire old items to keep the cache size at or under the item-cache-size. However when I look at the cache stats in the Dynamo admin console, I see several of our items have usedRatios of 500-1000%. This is hogging all of the memory in the JVM over time as more and more items are cached and apparently never released. If I invoke the invalidateCaches method on the Repository in the admin console the free memory jumps back way up and then the slow march down begins again.
How can I ensure that the caches do not grow over their configured size and take over all the memory? Is there some configuration setting I am missing? Are there code tricks one must employ to keep the cache from growing out of control? The ATG docs aren't the most informative and googling around hasn't yielded much info either.
After starting your ATG instance, I suggest navigating to the ProfileAdapterRepository in the Dynamo Admin page (/dyn/admin/nucleus/atg/userprofiling/ProfileAdapterRepository/?propertyName=definitionFiles) and viewing the combined view of the repository definition files. It's the best way to be sure what the final file looks like, since it can be built up of many files.
You should see the attributes you've configured on the "user" repository item through this interface (Note all lower case).
If you don't see your attributes here then you probably don't have your repository definition file loaded, either the module you're working on isn't started or the file is not on the configuration path.