database upgrade: Step 1 of 2 complete

[MattRobertson]

OK we got thru the first of two upgrades this evening.

What we did this evening should go a long way towards eliminating the errors we were seeing, but it will be at the expense of speed. the forum should be noticeably slower (strictly speaking some things will be slower and some faster). this will last until the second phase of the upgrade is complete. At present that is scheduled for tomorrow night. So if we are running slow, it shouldn't be for long.

[PAPITO]

Thanks Matt for staying up the whole day!

We love you <3

lol



























Seriously though

[Jokersmokesem]

What do you mean papito you love him?!

Thanks Matt!

[rtr0id]

nothing like having to retype a pm at 5am.

i had to use task manager to get out of explorer just now.

just letting you know

keep up the good work...hehe

[rtr0id]

nothing like having to retype a pm at 5am.

i had to use task manager to get out of explorer just now.

just letting you know

keep up the good work...hehe

happened again this morning

different computer
different ISP
different house
same person behind keyboard

had to use task manager because explorer was locked up

[bryan_k47]

Thanks again Matt for all your hard work



Got a Database error again a few hours ago,,,, Not complaining just letting you know

[MattRobertson]

That would have been when we took the db server down to upgrade the database.

Step 3 is going to be adding more memory to the box once we figure out how much of an improvement this latest change is.

[concussion]

happened again this morning

different computer
different ISP
different house
same person behind keyboard

had to use task manager because explorer was locked up

Explorer?? What the hell Tony? Get on a real browser.

[SirCrush32]

Matt,

What OS you guys using for the DB? Is this a SQL DB? Is it clustered? What hardware is it on? Just asking out of curiosity. If you need any assistance let me know. Don't mind lending a helping hand.

[rtr0id]

Explorer?? What the hell Tony? Get on a real browser.

slow and steady wins the race

[novawagonmaster]

slow and steady wins the race

Lmfao!

[MattRobertson]

Matt,

What OS you guys using for the DB? Is this a SQL DB? Is it clustered? What hardware is it on? Just asking out of curiosity. If you need any assistance let me know. Don't mind lending a helping hand.

CentOS 5.7 64-bit. the db is mySQL and we just took it up to 5.5. No cluster. No RAID. a straight 3ghz Xeon 1-processor, 2-core box which, in today's market, is quite pricey for the config.

Last couple weeks, in order:

1. Upgrade to VB4 results in much heavier query traffic due to the nature of the beast
2. I start beating on the db config to pump up the thruput buffers, caches etc. to handle the added load.
3. Turns out VB also silently converted about five of the 385 tables to InnoDB type from myISAM. There's no mention of this in VB docs and I had to find out about it in a blog post bitching about same. All optimization done up to this point pretty much did bupkis for the InnoDB tables now running un-optimized in a bare config.
4. InnoDB optimization commences and alleviates some of the issues. Memory requirements shoot thru the roof. Nature of the beast.
5. The InnoDB conversion is a good thing since myISAM tables only support table-level locking and thanks to 1. above, we are pushed over a performance threshold and are running out of connections, which took some time to discover thanks to the joys of working with a hosted linux server where for much of the time I couldn't get at the error reporting (have I mentioned how much I hate linux?).
6. We figure out the connection issue and deal with it. Part of the solution requires a much more comprehensive conversion to InnoDB.
7. Conversion performed night before last. InnoDB tables are much more scalable regardless of load since they are ACID compliant etc. etc. Naturally they are also much slower. So performance yesterday sucked royally UNTIL
8. Conversion to mySQL 5.5.21 from 5.0.xx. 5.5 really shows the investment Oracle has put into the platform and InnoDB tables are significantly faster. HOWEVER
9. We need a bunch more RAM on the system to properly implement buffers and such for all the InnoDB tables. Thats next. Right now we are coasting on the native performance of the 5.5 version of mySQL, which is certainly an improvement over 5.0.

The above is not the whole story. And not even whats pissing me off at the moment. Just hitting the high points.

[SRT8_in_CT]

CentOS 5.7 64-bit. the db is mySQL and we just took it up to 5.5. No cluster. No RAID. a straight 3ghz Xeon 1-processor, 2-core box which, in today's market, is quite pricey for the config.

Last couple weeks, in order:

1. Upgrade to VB4 results in much heavier query traffic due to the nature of the beast
2. I start beating on the db config to pump up the thruput buffers, caches etc. to handle the added load.
3. Turns out VB also silently converted about five of the 385 tables to InnoDB type from myISAM. There's no mention of this in VB docs and I had to find out about it in a blog post bitching about same. All optimization done up to this point pretty much did bupkis for the InnoDB tables now running un-optimized in a bare config.
4. InnoDB optimization commences and alleviates some of the issues. Memory requirements shoot thru the roof. Nature of the beast.
5. The InnoDB conversion is a good thing since myISAM tables only support table-level locking and thanks to 1. above, we are pushed over a performance threshold and are running out of connections, which took some time to discover thanks to the joys of working with a hosted linux server where for much of the time I couldn't get at the error reporting (have I mentioned how much I hate linux?).
6. We figure out the connection issue and deal with it. Part of the solution requires a much more comprehensive conversion to InnoDB.
7. Conversion performed night before last. InnoDB tables are much more scalable regardless of load since they are ACID compliant etc. etc. Naturally they are also much slower. So performance yesterday sucked royally UNTIL
8. Conversion to mySQL 5.5.21 from 5.0.xx. 5.5 really shows the investment Oracle has put into the platform and InnoDB tables are significantly faster. HOWEVER
9. We need a bunch more RAM on the system to properly implement buffers and such for all the InnoDB tables. Thats next. Right now we are coasting on the native performance of the 5.5 version of mySQL, which is certainly an improvement over 5.0.

The above is not the whole story. And not even whats pissing me off at the moment. Just hitting the high points.

Meh ... childs play ... lol ...

I understand nothing of the above, but thanks for all the hard work Matt

[DET-TANK]

BUT thank you for all you guys do to make LXF what it is!

[MattRobertson]

We had a hitch in the giddyap overnight, with the forum going crazy last night until we wised up and just shut it off until I could be rousted out of bed to fix it. I've been posting this around so here goes again:

None of this had anything to do with the transition/upgrade. Sort of.

Our hosting company screwed up on our database upgrade of two days ago (you guys noticed its faster and isn't throwing errors anymore?); They did most of the job but forgot one part of it. They were supposed to fix that last night but the tech forced the database to shut down. This crashed a table that the forum needs to do all kinds of stuff. The tech didn't bother to read the logs when he restarted the db to find out if he'd caused any damage. So it took until 6 am when I got a phone call to find out we were up $hit creek.

Took two hours to repair the damage but we came back up around 8.

I know you guys want to blame the new forum software but that wasn't it :-)