Jump to content

Site very slow after upgrading to 3.4.0


Recommended Posts

Posted

Did it works, or you still having the Cpu spikes?

It looks like it's dropped down. Then again it is like 5 in the morning. I'll have to wait about 24 hours to really see.

  • Replies 89
  • Created
  • Last Reply
Posted

How do I check that?

I just checked the SQL management area, and I've got 149259 rows in backup_queue. That's twice as much as I've got in the posts rows (60k). This patch is a disaster. It's wrecked IP content, made my front page slow to load and chews through resources.

Posted

I just checked the SQL management area, and I've got 149259 rows in backup_queue. That's twice as much as I've got in the posts rows (60k). This patch is a disaster. It's wrecked IP content, made my front page slow to load and chews through resources.

Any tasks still running in your SQL Processlist?

Either run SHOW PROCESSLIST from the SQL Toolbox or click the menu item SQL Processlist.

If any tasks have been running for a while, then you might want to consider to copy the id of the sql query and do KILL <id>

edit: and you should be able to see system processes under Support -> Diagnostics -> Overview. See if any specific processes are using a lot of CPU.

If you're still unsure on the cause, you should submit a ticket to IPS.

Posted

I just checked the SQL management area, and I've got 149259 rows in backup_queue. That's twice as much as I've got in the posts rows (60k).

oh good lord.
open up adminsourcesclassesbackup.php
find:

private function _getBlackList()
	{
		/* @todo abstract this puppy */
        return array( 'admin_login_logs',

Add app cache tables for now(DO ABSTRACT IT IPS, I should also be able to spec fields with an application, this is dangerous!!!1111):

private function _getBlackList()
	{
		/* @todo abstract this puppy */
		return array( 'ccs_template_cache',
                            'admin_login_logs',

also... to be 100% honest, TRUNCATE the mentioned table and define(IPS_BACK_UP_ENABLED, 0); via constants.php at this moment anyway... that is dangerous at the moment... on a high-volume Content Install that is a server death sentence, and explains many of those rows... >.<

Posted

I've added 'app cache tables'. Let's see what happens. Thanks :smile:

Edit - looking good so far.


Edit - Don't think it worked. It has spiked to 100 again. :/

Posted

I've added 'app cache tables'. Let's see what happens. Thanks :smile:

Edit - looking good so far.

Edit - Don't think it worked. It has spiked to 100 again. :/

Even after you've disabled the task?
Posted

Edit - Don't think it worked. It has spiked to 100 again. :/

to be 100% honest, TRUNCATE the mentioned table and define(IPS_BACK_UP_ENABLED, 0); via constants.php at this moment.

Kill the beast, it is running 2 queries for every 'native' query not a select, one to a table that will never be cleared, and fill up endlessly, ccs_blocks cache replace== 1 boom, with a million others behind it.

edit or add a file called constants.php at root, if editing, add:

define(IPS_BACK_UP_ENABLED, 0);

below the opening <?php tag.

if creating, the file contents should be:

<?php
define(IPS_BACK_UP_ENABLED, 0);
?>
Posted

You are welcome to submit a ticket so we can investigate the issue.

http://community.invisionpower.com/resources/bugs.html/_/ip-board/backup-getblacklist-abstraction-direly-needed-r40096

at this very moment, ccs_blocks, ergo, literally {parse_block="key"}/php equivalent, is a hazard, i believe i provide between this topic and the tracker report clear evidence the backup system not only needs a rewrite to only include approved tables/fields through abstraction(I have tables/fields that would be useless to include in applications myself, and forcing the extra insert(write activity) on every non-select query one runs is inane), but also needs a patch in the core ips_DBRegistry::setDB so that it does not automatically extend the core driver and run all those queries every page load upon upgrade for a feature that is not supported, currently, the code just inserts row after row... forever, never being cleared, useless writes..... could you not handle this as task or something anyway?

This is basically giving the finger to every developer that is constantly profiling and ensuring efficiency in their code regarding database access.... you double the write access without bleeding asking.

I do not need to submit a ticket, any developer who looks at the code regarding this backup system and does not see the blatant efficiency flaws in the design of the system needs their head checked.

  • Management
Posted

The back-up system isn't finished which is why it's not been abstracted hence the to-do.

The backup code isn't loaded in ipsRegistry unless IPS_BACKUP_ENABLED is specifically set to 'true'. If the constant is undefined, it returns NULL as per the PHP documentation.

But thank you for your insight. :smile:

Posted

The back-up system isn't finished which is why it's not been abstracted hence the to-do.

The backup code isn't loaded in ipsRegistry unless IPS_BACKUP_ENABLED is specifically set to 'true'. If the constant is undefined, it returns NULL as per the PHP documentation.

But thank you for your otherwise condescending and scorn filled post. :smile:

Please explain why that class is loaded and overloading the default database object upon upgrade by default, and I can see said inserts into backup_queue in my debug footer for every content block? :smile:

  • Management
Posted

That was caused by the back-up task running which initiates the first run of the system.

The patch we released yesterday disables this task from running.

If you are seeing inserts in your debug blocks, then check to make sure you don't have IPS_BACKUP_ENABLED set somewhere.

Posted

That was caused by the back-up task running which initiates the first run of the system.

The patch we released yesterday disables this task from running.

If you are seeing inserts in your debug blocks, then check to make sure you don't have IPS_BACKUP_ENABLED set somewhere.

.... I fail to see what a task has to do with the loading and extension of the database object with it undefined, which will run these inserts, and is, I do not have that constant defined.

{root}adminsourcesclassesbackupdb.php

Is listed as a loaded file, these queries are run, and I just installed this fresh from client center mere hours ago, after patch release.

If I am being 'scolding' and 'scathing' it is because even if this improper 'default' was not occurring, I am in no way happy knowing every write doubled is the method you built it on, it makes raw db connections lighter than the registry's db object for writes if this 'feature' is enabled. :wacko:

  • Management
Posted

.... I fail to see what a task has to do with the loading and extension of the database object with it undefined, which will run these inserts, and is, I do not have that constant defined.

{root}adminsourcesclassesbackupdb.php

Is listed as a loaded file, these queries are run, and I just installed this fresh from client center mere hours ago, after patch release.

If I am being 'scolding' and 'scathing' it is because even if this improper 'default' was not occurring, I am in no way happy knowing every write doubled is the method you built it on, it makes raw db connections lighter than the registry's db object for writes if this 'feature' is enabled. :wacko:

Actually, frustratingly, despite the PHP documentation saying that an undefined constant will return NULL, what actually happens (at least with PHP 5.3) is that it is converted into a string and returned as true! Argh!

I've updated the zip and the patch to wrap with defined('...') which completely resolves the issue.

Posted

That was caused by the back-up task running which initiates the first run of the system.

The patch we released yesterday disables this task from running.

If you are seeing inserts in your debug blocks, then check to make sure you don't have IPS_BACKUP_ENABLED set somewhere.

does it ?

after applying patch I had to manually disable the task and kill processes. seemed fine since then, wondering if task had fired before patch applied is issue.

should I re-apply the patch?

Posted

Actually, frustratingly, despite the PHP documentation saying that an undefined constant will return NULL, what actually happens (at least with PHP 5.3) is that it is converted into a string and returned as true! Argh!

I've updated the zip and the patch to wrap with defined('...') which completely resolves the issue.

Don't you just love it when a doc lies? >_<

http://www.php.net/manual/en/ini.core.php

short_open_tags default is still wrong, I never use them, but for reference.... as I've seen random bits re: that around.

Thank you, that stopped it for me... my hope you find a cleaner way to do this even with it enabled is great, as the idea shows promise, but the implementation has got to be sane. :)

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...