[xwiki-users] control the size of the attachments temp storage?
Hello XWiki experts, at www.curriki.org, our two server-nodes are reaching limits in terms of storage. One of the things that take a lot of space are the logs, we have a clue how to manage that. Another thing that takes a lot of space is /var/tmp/ which contains temporary storages for the attachment deliveries. On one of the nodes, it's made of 14Gb and 12538 files. On the other, 23Gb and 29402 files. What are the risk of deleting the old files there? Is the server touching the files when it has served them so that files older than a day could be deleted if we need? (I think I know that it takes more time to deliver from the DB and create temp-storage than to use the temp storage) thanks in advance Paul
Hi, You can delete those files any time the server stops, unfortunately when it's running they are not safe to delete. There was an issue which lead to files accumulating over time after adverse shutdowns such as a JVM crash. http://jira.xwiki.org/browse/XWIKI-7748 To mitigate this issue with older systems it's prudent to clear out the temp directory from time to time. As far as controlling the total storage size, there isn't any method to limit it and I'm not sure how much sense that would make to add one since the attachments are already stored in the database. Thanks, Caleb On 11/11/2012 03:46 PM, Paul Libbrecht wrote:
Hello XWiki experts,
at www.curriki.org, our two server-nodes are reaching limits in terms of storage. One of the things that take a lot of space are the logs, we have a clue how to manage that.
Another thing that takes a lot of space is /var/tmp/ which contains temporary storages for the attachment deliveries.
On one of the nodes, it's made of 14Gb and 12538 files. On the other, 23Gb and 29402 files.
What are the risk of deleting the old files there? Is the server touching the files when it has served them so that files older than a day could be deleted if we need? (I think I know that it takes more time to deliver from the DB and create temp-storage than to use the temp storage)
thanks in advance
Paul _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Thank you Caleb, could answer the question as to whether the files with older modification dates are indeed not being served currently, provided the modification dates are older than any connection? thanks in advance Paul Le 12 nov. 2012 à 14:50, Caleb James DeLisle a écrit :
Hi,
You can delete those files any time the server stops, unfortunately when it's running they are not safe to delete. There was an issue which lead to files accumulating over time after adverse shutdowns such as a JVM crash. http://jira.xwiki.org/browse/XWIKI-7748 To mitigate this issue with older systems it's prudent to clear out the temp directory from time to time.
As far as controlling the total storage size, there isn't any method to limit it and I'm not sure how much sense that would make to add one since the attachments are already stored in the database.
Thanks, Caleb
On 11/11/2012 03:46 PM, Paul Libbrecht wrote:
Hello XWiki experts,
at www.curriki.org, our two server-nodes are reaching limits in terms of storage. One of the things that take a lot of space are the logs, we have a clue how to manage that.
Another thing that takes a lot of space is /var/tmp/ which contains temporary storages for the attachment deliveries.
On one of the nodes, it's made of 14Gb and 12538 files. On the other, 23Gb and 29402 files.
What are the risk of deleting the old files there? Is the server touching the files when it has served them so that files older than a day could be deleted if we need? (I think I know that it takes more time to deliver from the DB and create temp-storage than to use the temp storage)
thanks in advance
Paul _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
That's not a guarantee unless the modification date predates a restart of the wiki. If you don't want to restart (who does) a cache flush should also release the rest of the files from use. Thanks, Caleb On 11/12/2012 09:48 AM, Paul Libbrecht wrote:
Thank you Caleb,
could answer the question as to whether the files with older modification dates are indeed not being served currently, provided the modification dates are older than any connection?
thanks in advance
Paul
Le 12 nov. 2012 à 14:50, Caleb James DeLisle a écrit :
Hi,
You can delete those files any time the server stops, unfortunately when it's running they are not safe to delete. There was an issue which lead to files accumulating over time after adverse shutdowns such as a JVM crash. http://jira.xwiki.org/browse/XWIKI-7748 To mitigate this issue with older systems it's prudent to clear out the temp directory from time to time.
As far as controlling the total storage size, there isn't any method to limit it and I'm not sure how much sense that would make to add one since the attachments are already stored in the database.
Thanks, Caleb
On 11/11/2012 03:46 PM, Paul Libbrecht wrote:
Hello XWiki experts,
at www.curriki.org, our two server-nodes are reaching limits in terms of storage. One of the things that take a lot of space are the logs, we have a clue how to manage that.
Another thing that takes a lot of space is /var/tmp/ which contains temporary storages for the attachment deliveries.
On one of the nodes, it's made of 14Gb and 12538 files. On the other, 23Gb and 29402 files.
What are the risk of deleting the old files there? Is the server touching the files when it has served them so that files older than a day could be deleted if we need? (I think I know that it takes more time to deliver from the DB and create temp-storage than to use the temp storage)
thanks in advance
Paul _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
participants (2)
-
Caleb James DeLisle -
Paul Libbrecht