Problems, need help? Have a tip or advice? Post it here.
9 posts Page 1 of 1
Hi KK

Recently, our webserver hang because every singe request to CouchCMS produces a sql data transfer as large as about 400 MB.

Digging into the code we found a code fetching the whole table 'couch_settings' in couch/functions.php on line 2320:
Code: Select all
$rs = @mysql_query( 'select * from '.K_TBL_SETTINGS, $DB->conn );

Looking at the datatable 'couch_settings', it has a size of 559 MiB (phpMyAdmin).

    - What ist this table for?
    - Can I reduce its size?
    - If yes, how?

This is a severe problem we were slipping in, so any quick help is highly appreciated.

Regards,
Olliwalli
Hi,

Please try this -
in couch/header.php you'll find the following (line 63 in the current version)
Code: Select all
define( 'K_CACHE_SETTINGS', '1' );

Edit it to turn the setting off as follows -
Code: Select all
define( 'K_CACHE_SETTINGS', '0' );

Please let me know if this rectifies the issue.
Thanks. I tried and found out that now it only creates an element in couch_settings first time I load a template. Every succeeding access to this template does not create an extra element.

Before I emptied the table an added the first few lines defining the installation variables.

Does deleting the cache elements in this table affect the proper working of couch in any way?
Does deleting the cache elements in this table affect the proper working of couch in any way?

As a rule of thumb, if a record has a key that is *not* human-readable e.g. 08f45742fcfadb1df8e438d006d132fb, you may safely delete it.
If, however, the key makes sense e.g. 'k_couch_version' or 'nonce_secret_key' then it shouldn't be messed with.
I think I need to clarify one more thing -
you don't really need to bother with the settings table; it will grow again over time but that is ok.
The size of the table was not the cause of your problem - it was Couch's attempt to fetch it all into memory at once that was causing the issue.

By setting 'K_CACHE_SETTINGS' to '0' we now stop this from happening and so you shouldn't come across the reported issue again.

Hope this helps.
Thanks!

It now performs faster and with very little data transfer loading. The table couch_settings still increases its number of records, but I can flush it from time to time if necessary.

Regards,
Olliwalli
Now, after some hours, I see that the table couch_settings is growing again. Is this probably a bug? Ore are sessions from anonymous users stored here (in about three hours there are about 360 new entries)?
It appears you missed one of my past reply in this thread. I'll paste it here -
I think I need to clarify one more thing -
you don't really need to bother with the settings table; it will grow again over time but that is ok.
The size of the table was not the cause of your problem - it was Couch's attempt to fetch it all into memory at once that was causing the issue.

By setting 'K_CACHE_SETTINGS' to '0' we now stop this from happening and so you shouldn't come across the reported issue again.

In a bid to make things a bit faster, Couch caches the *compiled* output of your snippets (i.e. the 'op-codes') and this shows up in the table in question. So, depending on how many snippets your site deploys and their sizes, the entries will vary but will reach a finite number sooner or later.

The size of the table in the database shouldn't be a factor but if it is for you, you may turn this behavior off by setting the following in couch/header.php to '0' -
define( 'K_CACHE_OPCODES', '1' );

Hope this answers your query.
Thank you very much, I appreciate your quick and enlightening answers a lot!
9 posts Page 1 of 1