I still would like to have a wiki page that does some more explaining of the monitor graphs :) We have an environment where the clustersize has grown the last couple of days (see graph) My first thougt was that the database has grown, but downloading it does not give a bigger size then normal. Is my assumption wrong (the mother of all f* ups)? What could be an explanation? Regards, Ronald [EDIT] This issue was the start of some serious problems on this environment and I want to share some lessons learned. We could not explain the growth of the database. We did deployed a new model just before the database started to double, but the changes could never result in a doubling of the database. We did use postgres statistics on the table to do some comparison. This was the result: Name entity Old lines New lines Old size New size basis$bankgiro 7194 7232 1904 kB 727 MB basis$bankgiro_medewerker 7194 7232 792 kB 30 MB basis$bovenliggendemanager 2277 2143 280 kB 21 MB For some reason we only had a small increase in data but the size of this data exploded. The result of the database growth was a diskspace warning. And here comes lesson number two. Making room by removing no longer needed filedocuments does not make the diskspace warning go away. Disk size of the database is separate of the diskspace of the filedocuments. So making room on one does not result in room for the other. The correct solution to get instance space on the production database is by shutting down the test or production environment and empty the database. The solution of the problem of the database is by stopping the environment, creating a backup and restore it. Since only real data is exported the emptying and restoring of the database resulted in the old sizes again. Two items are not solved for me. One: why did this growth happen and two: why did a vacuum (and here I assume again that Mendix does do a vacuum once and a while on the database) not result in a decrease of the database.? And here the result after the cleanup (red line prod, blue accp, green test): I hope this info is of some use if you come across a similair problem. Ronald
asked
Ronald Catersels
2 answers
0
The other graphs of this environment (the ones our support desk can see about your environment) show an abnormal amount of CPU usage going on for a few days last week, corresponding to the time frame of the growing database size. Did you run any huge, long running actions in the application?
answered
Hans van Kranenburg
0
Ronald,
Vacuum will not decrease size in most cases:
Normal vacuum doesn't (usually) shrink table files. It just moves the rows around in table, to make sure that pages are as full as possible. If it will happen that there are some 100% empty pages as the very end of table file – they will get removed, and table size decreased. But that's not very common.
Vacuum FULL will do this trick but this would cause issues because of locking that is needed for this function.
This explains more on why your db size did not decrease, can't comment on why it increased in the first place.