News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Forum is frozen. Infinite sql loop while post/edit/modify/save

Started by Maxtor, April 13, 2013, 10:33:34 PM

Previous topic - Next topic

HYPERFILTER

Quote from: Arantor on April 13, 2013, 11:32:04 PM
It's a valid question.

But look at it this way: nothing else, apparently, changed. No mods, no PHP upgrade. The *only* thing that's changed is the data - there's more of it.

From what I've seen thus far, the only logical conclusion is that you're going over limits you weren't going over before. But seriously, there is absolutely no good reason to be using MyISAM on the messages table.

The PHP version changed, but this was around 10 days ago, from 5.3.17 to 5.3.23, although the complaints started just today.

Maxtor is giving a try converting the table to InnoDB to see what happens.

Arantor

Looking back at the PHP changelog, I see only one reference to a loop bug, but that's only for file_get_contents with a cURL wrapper - which isn't invoked as far as I can tell, and that was fixed in 5.3.18)

Says to me that it's not the issue at hand.

HYPERFILTER

Quote from: Arantor on April 13, 2013, 11:38:46 PM
Looking back at the PHP changelog, I see only one reference to a loop bug, but that's only for file_get_contents with a cURL wrapper - which isn't invoked as far as I can tell, and that was fixed in 5.3.18)

Says to me that it's not the issue at hand.

Yeah, I also was digging into that and didn't saw anything significative.

Maxtor

smf_messages converted with code:

ALTER TABLE smf_messages
TYPE=InnoDB;

but the problem is still there :/

HYPERFILTER

Ok, converting it to InnoDB, didn't changed anything, the problem still persisted.

Arantor

-sigh-

I find it so frustrating to have to keep asking questions over and over and over.

1. Did you set the buffers properly for using InnoDB?
2. Are you using proper UTF-8 for the forum and database tables?

You know, you don't *have* to post the same thing twice between you...

*yawn* It's nearly 5am, bedtime.

HYPERFILTER

Quote from: Arantor on April 13, 2013, 11:50:56 PM
-sigh-

I find it so frustrating to have to keep asking questions over and over and over.

1. Did you set the buffers properly for using InnoDB?
2. Are you using proper UTF-8 for the forum and database tables?

You know, you don't *have* to post the same thing twice between you...

*yawn* It's nearly 5am, bedtime.

1) 10 GB buffer, should be enough for a 1G table, so yes, it is ok.
2) Yes, the messages table is in utf-8, others are not, but this table in question, is UTF-8.

Some more informations regarding the database :

>>  MySQLTuner 1.2.0 - Major Hayden <[email protected]>
>>  Bug reports, feature requests, and downloads at http://mysqltuner.com/ [nofollow]
>>  Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.68-cll
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 2G (Tables: 4279)
[--] Data in InnoDB tables: 2G (Tables: 758)
[--] Data in MEMORY tables: 1M (Tables: 23)
[!!] Total fragmented tables: 296

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 56m 14s (2M q [357.427 qps], 185K conn, TX: 71B, RX: 338M)
[--] Reads / Writes: 69% / 31%
[--] Total buffers: 5.0G global + 2.7M per thread (2048 max threads)
[OK] Maximum possible memory usage: 10.5G (22% of installed RAM)
[OK] Slow queries: 0% (18/2M)
[OK] Highest usage of available connections: 3% (62/2048)
[OK] Key buffer size / total MyISAM indexes: 8.0M/972.8M
[OK] Key buffer hit rate: 98.3% (21M cached / 371K reads)
[OK] Query cache efficiency: 60.9% (929K cached / 1M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 9% (6K temp sorts / 60K sorts)
[OK] Joins performed without indexes: 1158
[OK] Temporary tables created on disk: 32% (20K on disk / 61K total)
[OK] Thread cache hit rate: 99% (62 created / 185K connections)
[OK] Table cache hit rate: 99% (256 open / 27K opened)
[OK] Open file limit used: 3% (352/10K)
[OK] Table locks acquired immediately: 99% (1M immediate / 1M locks)
[OK] InnoDB data size / buffer pool: 2.0G/10.0G

Maxtor


LiroyvH


$db_show_debug = true;


in Settings.php should cover that.
((U + C + I)x(10 − S)) / 20xAx1 / (1 − sin(F / 10))
President/CEO of Simple Machines - Server Manager
Please do not PM for support - anything else is usually OK.

HYPERFILTER

Quote from: CoreISP on April 14, 2013, 12:55:16 AM

$db_show_debug = true;


in Settings.php should cover that.

Hm, in our case it is not of so much help, since it doesn't generate a log file during the runtime, to find out where the code would be looping :(

Maxtor

i have noticed that [img][/img] is shown as [IMG][/img] , IMG shows in caps . is it normal?

MrPhil

Is there anything at all "different" about the failing "big" posts, other than their size? Could these big posts have been cut and pasted from Word, bringing over strange "Smart Quotes" characters that can cause problems on some systems? Usually the ill effect is that the rest of the post gets cut off, not an infinite loop somewhere, but who knows.

italic using caps. Nope, BBCode is case-insensitive.

Advertisement: