Hi,
We are using AEM 6.1 and 1 month before we have upgraded to community FP6, also installed SP2 and CFP3. After this installation on publish and author both we experienced that on Author, repository size increased to 67 GB which was earlier 47GB only. But publish won't increased this much.
We have almost same content on both the servers. And also we are performing Offline-Compaction(bi-weekly) on both. Post this compaction publish always decreased near to it's previous size but author won't. Author also compressed but not this much. Which makes Author repository size increasing gradually.
Any suggestion why this difference we have and any suggestion to further reduce the size.
Thanks
Manoj Singh
Solved! Go to Solution.
First of all, I don't think that the growth of the repository is directly tied to CFPs or Servicepacks. It is much more likely that the growth is caused by a different usage of the system, for example by uploading a bunch of assets, which triggered the rendering of renditions etc.
if you are concerned about disk usage, you should establish a permanent monitoring including a visualization over time. This helps you to find out if the content steadily grows and grows or if there was a sudden increase; and if there was an increase, this data helps you to identify at which date it happens, and then you can start investigating what happened around that date.
Author and publish will always be different in size, because you typically have much more data on author (e.g renditions only used for authoring purposes, audit data, versions, etc). That's normal and nothing to worry about.
Following the suggestions of Yadav can help you to find out more about it.
Jörg
Jörg Hoh Need pointers from you here!!
Views
Replies
Total Likes
Hi Manoj,
It's always expected that author will take more disk space compare to publish and there could be several reasons one of them is lots of versions gets generated on author compare to publish which really lead to size .
Are you running garbage collection and version purging?
Compare size of these 3 directories ( repository, index & segmentstore) under \crx-quickstart\repository and share result ?
Compare disk usage for versioning using report http://localhost:4502/etc/reports/diskusage.html?path=/jcr:system ?
/Brijesh Yadav
First of all, I don't think that the growth of the repository is directly tied to CFPs or Servicepacks. It is much more likely that the growth is caused by a different usage of the system, for example by uploading a bunch of assets, which triggered the rendering of renditions etc.
if you are concerned about disk usage, you should establish a permanent monitoring including a visualization over time. This helps you to find out if the content steadily grows and grows or if there was a sudden increase; and if there was an increase, this data helps you to identify at which date it happens, and then you can start investigating what happened around that date.
Author and publish will always be different in size, because you typically have much more data on author (e.g renditions only used for authoring purposes, audit data, versions, etc). That's normal and nothing to worry about.
Following the suggestions of Yadav can help you to find out more about it.
Jörg
Hello Jorg,
In my case the author is consuming less space than the publisher, after running the weekly maintenance task the disk space on the author instance is reduced to less than 20 GB but in my publish environment its still 40 GB, even though I have ran the same maintenance task there as well.
Can someone please help me figure this out
Regards,
Prakash Iyer
Views
Replies
Total Likes
Well, that's weird then. This means that you either have more active content on publish than on author (which is rather unlikely, because I hope that someone would have found that already), or that you have some garbage on your publish system you are not aware.
You could use the Disk usage report (/etc/reports/diskusage) to find out how much content (in nodes and bytes) is stored in which subtree. Try that first on a lower environment to get an impression about the performance impact (it's very resource intensive).
Jörg
Views
Replies
Total Likes
Views
Likes
Replies