It is a bug due to Ensemble code adding routines to the set of items generated by the class but not setting the timestamp for these. So when we look at all routines generated from this class and verify the timestamps of each one has not changed these are different and so cause the flag showing it is not up to date.

As there is pre-existing code that sets this $$$cCLASSroutines array manually I updated the logic to only verify timestamps that are not "" which should fix this problem. This fix was submitted as MAK4540.

While ^GLOBUFF is useful for showing the makeup of the current global buffer pool it is not really useful for sizing the buffer pool. If for example ^GLOBUFF shows that ^MyLogGlobal is using a lot of the buffer pool you may want to investigate if you are logging too much data and if this is pushing your main application globals out of the buffer pool sooner.

Most applications will not have sufficient memory to allow their entire working set to reside in the buffer pool so it is perfectly normal for the buffer pool to be 100% used as shown by ^GLOBUFF. The point of the buffer pool is to cache values in memory to avoid disk IO, so to size this use a tool like ^mgstat which shows global references and and physical reads. If the physical reads is too high try increasing the buffer pool in the hope that caching more data will reduce the disk IO.

On the original question my general rule is the user should be able to calculate how many processes they will need to run their application and measure how much memory each process takes and so calculate how much memory will be needed for this. Then based on the total available memory on the machine they can subtract this out, and allocate say 70% of the remaining to the global buffer pool. However like any performance related issue the only way to know for sure is to measure and be willing to update your configuration based on these measurements.

The RSS feed for groups (or communities as the link currently says) does not include a title, e.g. for:

https://community.intersystems.com/group/8081/feed

Starts with:

    <title></title>
    <link>https://community.intersystems.com/group/8081</link>
    <description></description>

So there is no title or description of this feed. Also is there a feed for all content posted to this site, so not filtered by tag/group at all?

Thanks John, hint taken, I have just checked in a change to the SAMPLES to remove direct calls to %apiOBJ.

The worker jobs do not have access to the memory of the master process. These are just regular Cache processes. If you wish to share information between jobs then use globals and locks to synchronize access to pieces you need to change.

I think they should disable the points totally until they figure out exactly how they will be used.

There is a white paper on this topic based on Intel hardware here:

http://www.intersystems.com/assets/High_Performance_Encryption_for_Databases_in_Financial_Services.pdf

+2 :-)

The syntax is great as it exactly expresses what you want to achieve, however if your code is performance critical it is faster to:

Set r=$list(colors,1),o=$list(colors,2),y=$list(colors,3)

Hopefully the 'set $lb' syntax will be optimized at some point as it is clearer than the multiple $list alternative and it should be possbible to make it faster.

Both these issues are addressed in the version we have scheduled for 2016.2.

Previousy the worker jobs are owned by the process asking for the work, in the new version we have a global pool of jobs available for any work. This allows the work queue manager to work in CSP processes. Also when you ask for a work group you can now specify how many processes you require.

Note that the 'ForceJobs' setting is unsupported and undocumented so we may remove it at some point.