Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Mack_au Posted November 28, 2012 Posted November 28, 2012 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.
Ocean West Posted November 28, 2012 Posted November 28, 2012 are you sure your not hacked? my symptom was my cpu spiked and took out my machine we even added 8GB of ram and it still used that up and took out the dedicated server.
RevengeFNF Posted November 28, 2012 Author Posted November 28, 2012 My site is flying again since the Patch. Problem Solved :)
Mack_au Posted November 29, 2012 Posted November 29, 2012 I patched. Mine is still wrecked. Luckily my host haven't got mad at me yet, but I'm CPU limited almost all the time now :S
nylyon Posted November 29, 2012 Posted November 29, 2012 What process is consuming the most CPU on your system?
Mack_au Posted November 29, 2012 Posted November 29, 2012 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.
TSP Posted November 29, 2012 Posted November 29, 2012 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.
Mack_au Posted November 29, 2012 Posted November 29, 2012 I've already got a ticket open. So far it's been less than helpful. There doesn't look like there is any tasks ongoing.
Marcher Technologies Posted November 29, 2012 Posted November 29, 2012 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... >.<
Rimi Posted November 29, 2012 Posted November 29, 2012 Oh man...lol Well marcher, the service is delayed after all.
Mack_au Posted November 29, 2012 Posted November 29, 2012 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. :/
HeadStand Posted November 29, 2012 Posted November 29, 2012 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?
Marcher Technologies Posted November 29, 2012 Posted November 29, 2012 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); ?>
Management Matt Posted November 29, 2012 Management Posted November 29, 2012 You are welcome to submit a ticket so we can investigate the issue.
Marcher Technologies Posted November 29, 2012 Posted November 29, 2012 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 Matt Posted November 29, 2012 Management Posted November 29, 2012 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:
Marcher Technologies Posted November 29, 2012 Posted November 29, 2012 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 Matt Posted November 29, 2012 Management Posted November 29, 2012 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.
Marcher Technologies Posted November 29, 2012 Posted November 29, 2012 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 Matt Posted November 29, 2012 Management Posted November 29, 2012 .... 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.
Dmacleo Posted November 29, 2012 Posted November 29, 2012 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?
Management Matt Posted November 29, 2012 Management Posted November 29, 2012 Go ahead and download the patch and re-upload 'admin/sources/base/ipsRegistry.php' to be sure.
Marcher Technologies Posted November 29, 2012 Posted November 29, 2012 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. :)
RevengeFNF Posted November 29, 2012 Author Posted November 29, 2012 I have download the last Patch. In the System Scheduler i have the task "Back Up Batch Send" enabled. Should i disable it, or leave it that way?
Recommended Posts
Archived
This topic is now archived and is closed to further replies.