Portal Engine Questions on portal engine and web parts.
Version 5.x > Portal Engine > Website Size Growing Rapidly View modes: 
User avatar
Member
Member
michael-thefamousgroup.com - 5/3/2010 5:36:18 PM
   
Website Size Growing Rapidly
Hi

Can anyone explain why the size of Kentico sites grows so fast (and large) even on sites that are not being updated regularly?

All of our Kentico sites start around 200MB and within a few months they are generally over 1GB in size. One site which has infrequent updates (once a month) is over 3GB. This is causing some issues with our hosting, but I was generally wondering what causes this so I can explain it to your clients as it is not files/content being added to the site. The site is generating the extra size itself.

Is there anything that can be deleted to reduce this? Log files etc?

Thanks
Michael

User avatar
Kentico Support
Kentico Support
kentico_jurajo - 5/4/2010 2:27:23 PM
   
RE:Website Size Growing Rapidly
Hi,

Are the content staging or web farms module configured for this web site?
Could you please get the size of database tables so we can see the biggest tables? Then we will be able to tell you more what is causing this.

Moreover, what is the setting for storing files? Are you storing them in the DB or in file system?

Best regards,
Juraj Ondrus

User avatar
Member
Member
michael-thefamousgroup.com - 5/8/2010 4:41:54 AM
   
RE:Website Size Growing Rapidly
Hi

Thanks for getting back to me so quickly!

Unfortunately I am unfamiliar with your questions as these sites have just used the standard install and we don't change any settings. So my questions back are:

1. How do I tell of the content staging or web farm modules are configured?
2. How do I tell if we are storing files within the database or file system?

And I will try and get the size of the database tables for you.

Thanks
Michael

User avatar
Kentico Support
Kentico Support
kentico_jurajo - 5/11/2010 5:47:02 AM
   
RE:Website Size Growing Rapidly
Hi,

You can check whether mentioned modules are set by checking if these things are set:
Web farms
Content staging
Files storage

It would be great if you couold tell us which of the DB tables are the biggest.

Best regards,
Juraj Ondrus

User avatar
Member
Member
michael-thefamousgroup.com - 5/25/2010 6:54:21 AM
   
RE:Website Size Growing Rapidly
Hi

Sorry for taking so long to reply. Here is some more info:

1. Web Farms - not configures
2. Content Staging - Log export tasks enabled only
3. Files Storage - Store Files In Database is enabled

Is point 3 the reason? And can I just switch that off now without effecting the performance of the websites?

And I'll get some info on the DB tables shortly.

We're also finding that the sites are steadily growing even without updates being added to the sites - how is that possible?

Thanks
Michael

User avatar
Kentico Support
Kentico Support
kentico_jurajo - 5/25/2010 2:14:21 PM
   
RE:Website Size Growing Rapidly
Hi,

If you are storing files in the database, then all files and their data are placed there - which can be space consuming. You can set the files storage to be on file system (existing files will be kept in the DB), also file system is faster for performance - http://devnet.kentico.com/docs/devguide/where_the_files_are_stored.htm.

Could you please script the database to get the tables sizes so we can see which tables are the biggest?

Also, if there are no updates, what are your backup settings? Maybe the backup runs every few hours and creating new backup files on the disk. Also, are you using full transaction log?

Best regards,
Juraj Ondrus

User avatar
Member
Member
michael-thefamousgroup.com - 5/25/2010 9:58:54 PM
   
RE:Website Size Growing Rapidly
Hi

Thanks for the speedy response and just some quick questions from me:

I notice in the file settings you can set it so both "store files in database" and "store files in system" can be left unticked. Is this ok? Or does "store files in system" have to be ticked if the database option is not ticked?

With regards to your further questions:

1. Backup settings - are you referring to our server backups or is this a Kentico CMS setting you are referring to?

2. Where do we see what our transaction logs are set? Again is this a Kentico CMS setting?

Many thanks
Michael

User avatar
Member
Member
michael-thefamousgroup.com - 5/25/2010 10:02:01 PM
   
RE:Website Size Growing Rapidly
And just another quick addition - I've just checked and the size is definitely the database - our most recent site's database is 800MB already. I will now get back to you with info on which tables are the largest.

User avatar
Kentico Support
Kentico Support
kentico_jurajo - 5/27/2010 2:48:49 AM
   
RE:Website Size Growing Rapidly
Hi,

The information about the DB tables sizes will help us much more than my assumptions right now.

The files have to be stored somewhere - so one of those options or both have to be checked.

1) In Kentico CMS there is no backuping, I referred to the SQL server settings
2) This is again MS SQL server settings.

Could you please contact your system/network/DB administrator to check those settings?

Best regards,
Juraj Ondrus

User avatar
Member
Member
michael-thefamousgroup.com - 8/5/2010 12:42:49 AM
   
RE:Website Size Growing Rapidly
Hi

Sorry about my silence on this - got very sidetracked! We have spent some more time looking into this and we currently believe it's a server transaction log that is causing the issue. This will be confirmed tomorrow so I will update if useful to anyone else who has this problem.

Thanks
Michael

User avatar
Member
Member
lancetek - 9/8/2011 3:34:49 AM
   
RE:Website Size Growing Rapidly
Sorry to hijack the thread, but I'm seeing our Kentico db grow rapidly, and I thought our details would be helpful to others.

Our Situation:
In a week, our db went from 30Mb to >2GB! This had me worried, since at this rate we would soon run out of space on the partition, perhaps have windows 'large file' problems and the performance was degrading by the hour.

After reading Jurajo's suggestions:
- Keeping files in the Db will grow the db
- Content staging will grow the db too - depending on how much activity you have, and how big the sources that are being tracked are.
- don't know about web farming


To help diagnose exactly what was taking up all the space, I used my 'Space diagnosis script' (see below). Here's what by DB looked like:

table_name             rows     reserved (KB) data (KB) index size (KB) unused (KB)
---------------------- -------- ------------- --------- --------------- -----------
Staging_Task           188575   1621752       1575288   44464           2000
CMS_AttachmentHistory  2593     121320        119984    760             576
CMS_User               56051    110016        47664     61744           608
CMS_VersionHistory     6438     65520         62960     1456            1104
Staging_Synchronization 488792  26712         14920     11496           296
CMS_UserSettings       56051    20128         5728      13480           920
CONTENT_article        2509     16528         16320     56              152
CMS_DocumentAlias      8357     14256         2696      10080           1480
Newsletter_Subscriber  35375    13720         9952      3656            112
CMS_Document           6406     12608         6848      4184            1576
CMS_Tree               6990     9136          2496      4864            1776
CMS_PageTemplate       265      6920          6472      200             248
CMS_WebPart            281      4144          3864      112             168
CMS_Class              235      3720          3088      424             208
CMS_MetaFile           600      3104          2536      208             360
CMS_EventLog           2252     2888          1912      560             416
CMS_SearchTask         13426    2632          1616      664             352
Newsletter_SubscriberNewsletter 68206 2312    2280      16              16
CMS_Attachment         2851     2080          632       928             520
Export_History         21       2056          1896      56              104

I didn't even bother listing the next hundred tables...


This makes it quite clear what is taking up the space. Here's how we got here:
- We are near the end of developing a moderately-sized website.
- In the last week we've imported 6000+ Articles and 60,0000 users.
- And we are using Content Staging.
- And we are using workflows with Versioning.
- And we have lots of the 60,000 users assigned to one or more Newsletters.
- And we have ~50 page templates.

Cause and effect.

Staging is obviously the real pig here. 1.6GB of piggishness. This morning I had over 180,000 staging tasks listed in the cmsdesk! That was easy enough to deal with, I deleted them using the cms desk. I'll pick and choose objects to move manually later; 1.6GB is just too crazy a size to keep.

AttachmentHistory is the next culprit. I'm not sure how to deal with this, I'd like some pointers from someone on what to do to minimize this - we don't really need much of a history of attachments. I'm guessing this is related to versioning somehow.
Users is big too, but we have lots of Users, so I doubt we can reduce the size.
VersionHistory is big... we are keeping the last 10 versions by default. I suppose we could reduce that to the last 5 or something to reduce that? If I change the setting to a lower number, will the older versions get deleted automatically? Or do we need to 'touch' a document to trigger the setting?

The rest of the table sizes look reasonable for what we are doing with Kentico.








Space diagnosis script for SQL Server

--NOTE: I can't remember where I got this from... it works really well and the author should get some credit.

CREATE TABLE #temp (Table_Name nvarchar (128), Rows char(11), reserved varchar(18), data varchar(18), index_size varchar(18), unused varchar(18))


declare @table_name sysname,
@sql_string nvarchar(1000),
@count nvarchar(1000);



set nocount on
declare all_tables cursor for
select TABLE_NAME from information_schema.tables WHERE TABLE_TYPE = 'BASE TABLE'

open all_tables

fetch next from all_tables into @table_name

while @@fetch_status=0

begin
CREATE TABLE #tempTable (Table_Name nvarchar (50), Count int)
--set @sql_string = N'select count(*) as ['+@table_name+'] from ['+@table_name+']'
--set @count = 'select count(*) from ['+@table_name+']'

--set @sql_string = N'select count(*) as ['+@table_name+'] into #tempTable from ['+@table_name+']'
--set @sql_string = 'insert into #temp (Count)['+@table_name+'], select count(*) from ['+@table_name+'])'

--PRINT @sql_string
--exec (@sql_string)

set @sql_string = N'INSERT into #temp exec sp_spaceused ['+@table_name+']'

PRINT @sql_string
exec (@sql_string)



drop table #temptable
fetch next from all_tables into @table_name
end


close all_tables
deallocate all_tables
set nocount off

select table_name
, [rows]
, convert(int, substring(reserved, 1, len(reserved) -3)) as [reserved (KB)]
, convert(int, substring(data, 1, len(data) -3)) as [data (KB)]
, convert(int, substring(index_size, 1, len(index_size) -3)) as [index size (KB)]
, convert(int, substring(unused, 1, len(unused) -3)) as [unused (KB)]
from #temp
order by [reserved (KB)] desc

--drop table #temp


User avatar
Kentico Support
Kentico Support
kentico_jurajo - 9/12/2011 2:48:06 AM
   
RE:Website Size Growing Rapidly
Hi,

Content staging - are you using this module to synchronize the changes? I would recommend you to do it on regular basis to avoid 180,000 records in the DB. You can also use automatic synchronization for some parts. If you are not using content staging, please disable the changes logging in Site Manager -> Settings -> Content staging section.

Users - 60,000 users is pretty big number. Right now I do not have any suggestions how to optimize this.

VersionHistory & AttachmentHistory - if you are using workflow and versioning the previous version of the documents and attachments (in case of an attachment the history includes its binary data too) have to be stored somewhere in case you want to roll it back. Yes, you can set the version history length to a lower number and if the length is exceeded for particular document, the older versions are automatically destroyed without any option to restore them (unless using DB backups).

Best regards,
Juraj Ondrus

User avatar
Member
Member
Punt - 1/9/2012 9:33:57 AM
   
RE:Website Size Growing Rapidly
Hi Juraj,

We disabled content staging because we don't use this module any more. But the table contains 900MB of data. Is it save to delete the records in the Staging_Task table? Or can this be done in the CMSDesk?

Regards,
Edgar Apeldoorn

User avatar
Kentico Support
Kentico Support
kentico_jurajo - 1/10/2012 2:35:05 AM
   
RE:Website Size Growing Rapidly
Hi,

You can delete it directly in the database (which might be faster) or then in the UI and delete the tasks in the content staging section by selecting the tasks you want to delete (there might be several clicks needed to go through all tasks).

Best regards,
Juraj Ondrus

User avatar
Member
Member
Snarrak - 2/3/2012 3:47:05 AM
   
RE:Website Size Growing Rapidly
Hi I'm having this problem with Attachment_VersionHistory table.

Is it save to delete records from this table (maybe all records)? My attachments on the site won't be affected, because the are in the CMS_Attachment table?

It isn't possible to do this directly in the database, because there's a n PK relationship with the table CMS_VersionAttachment. Is it also save to delete these records?

Where are the settings for the attachment versioning? I don't have object versioning or staging.

Regards,
Jorik

User avatar
Kentico Consulting
Kentico Consulting
kentico_borisp - 2/6/2012 6:41:15 AM
   
RE:Website Size Growing Rapidly
Hello,

The most straightforward solution would be to use our own settings:

The Version History length can be set in SiteManager / Settings / Content Management as

Version history length - Specifies maximum number of versions in the document history. If the number of versions exceeds the specified maximum number, the older versions are destroyed.

I would suggest you to use our API for deleting the version history, since deleting database entries could cause inconsistencies in the system. The method in VersionManager that is deleting the older versions is DeleteOlderVersions(int documentId, string siteName).

You can also save the files in the file system so the database won't grow with new files added to the system. This setting is in CMSSiteManager / Settings / System / Files / Store files in file system. Here uncheck the Store files in database box.

Best regards,
Boris Pocatko