vBulletin performance (& TPD)

[BrowneIssue]

Too many DB connections, the DB server is struggling with TPD. Night is drawing in on the thread I am afraid.

Performance analysis of systems (not just databases or code execution or networks but entire systems) used to be one of my specialist areas. IMHO, the conclusion above is a non sequitur.

"Too many db connections" is a symptom, not a problem. By working out why that is happening, a variety of solutions will be discovered, most of which will warrant implementation.

A database is a living, evolving thing. It changes shape with time. It moves. Some bits get old and stagnant, young fresh growth occurs in unexpected places, often all over the place. It needs pruning, repotting, spraying and lots of TLC. Hacking off 20% of the trunk will not make it produce better apples.

Deleting TPD comes across as "we need to be seen to do something, so we'll do something to amuse the baying public then it's not our fault it if doesn't work". I think we can do better than that.


Without even looking at the box nor the detail of some of the suggestions already made, there is a list of likely areas of investigation that could yield huge performance improvements.

How is the server(s) configured? Is the o/s out of the box or tweaked for the role it is serving?

Hardware spec: how old is the box? How much RAM is needed and how much is there? How much free disk space is left?

Is it disk I/O bound? There's loads of fun to be had here, plus this is where most of the expertise is. But do not be distracted by fear of having a non-conformant database with weird indexes and the like; that is probably totally unnecessary. How is the data spread across the disk(s) and is balancing required? How has it being growing and does it need to be reorganised (a 'database defrag' if you like)? Would another drive controller or a couple of huge, cheap, faster drives help?

It is CPU bound? If so, why? What is running? There isn't a pretty screensaver or SETI@Home running taking up 100% of a CPU is there? (Seen that on a £2m setup; a huge SUN box spending 25% of its life running a fireworks screen saver on the oper console, FFS).

Is it n/w I/O bound? Is there a bottleneck between the CPU & the LAN (ie network card)? The network card and the building's connection to the outside world (LAN contention, dodgy hubs, crap wiring)?

Does the overall configuration warrant review? Is it one £1,000 box that was purchased in 2002 or a carefully maintained quartet of mirrored and load balanced dedicated file servers / dedicated application servers?

Is the service outsourced? Would switching to a specialist hosting service turn it into a fixed monthly cost but with far better performance and no maintenance issues? Would switching from outsourced to a dedicated server provide better performance and remove complexity from maintenance?

That's all easy stuff and before we even get into looking at the specialist skills areas of precise applications on those boxes and how they are performing (cue NickFitz's very generous activity). And any of those things might be the cause why a database connection timeout could occur.


Just lopping off one very popular, albeit silly, thread from your service seems a drastic and ill-conceived approach. Three or four of your users will be ecstatic, many others will stomp off in disgust. But you will have seriously damaged the 'culture' that is here. And quite likely only made an improvement to the performance of the system by losing half of your most active users.


Anway. Can I be of any help? I am willing. You know how to PM me.

[DimPrawn]

As others have said. Lock TPD thread. Everyone can still read it.

Create a TPD V2.

What is the big issue?

[NickFitz]

As others have said. Lock TPD thread. Everyone can still read it.

Create a TPD V2.

What is the big issue?

Ah, the typical .NET solution: "There's no need to address the root cause of the problem, we can use this ugly hack instead."

Works great... until next time

[DimPrawn]

Ah, the typical .NET solution: "There's no need to address the root cause of the problem, we can use this ugly hack instead."

Works great... until next time

It's called getting on with a business to maximise return and minimise time wasted, something techie monkey's don't understand.

Have a banana.

[BrowneIssue]

It's called getting on with a business to maximise return and minimise time wasted, something techie monkey's don't understand.

Have a banana.

This is Technical, not General. Behave or I'll your apostrophe usage.

It is short-sighted, cheap and dirty management kludges that cause the most pain later when it has to be fixed again, properly. Doing the job properly the first time is usually cheaper; it just doesn't get noticed or rewarded.

Hacking off threads arbitrarily is unlikely to repair file fragmentation when the database has already expanded to accommodate the space previously used. Deleting the records may do nothing to resolve poor index alignment brought about by adding one million records which have an autoincrementing key field.

If TPD is deleted and the space is re-used, disk I/O could get even slower as record fragments are 'seeked'; at least new records are currently being appended and so are contiguous.

If TPD is locked or deleted and no proper work is done on fixing the real problem (which is a technical problem, not a management problem) then it will not get any better. All it will achieve is to deal with your personal agenda. The real technical problem will still need to be addressed.

[minestrone]

Can you not start a new one just now and then merge them together after you do what ever you want to do to improve the performance of the system?

Then everyone is happy.

[TheFaQQer]

Just out of interest - has anyone had any problems with CUK today? I've not seen a database error (yet).

[Bunk]

Just out of interest - has anyone had any problems with CUK today? I've not seen a database error (yet).

Me neither. Well done NF, just threatening to look at the problem has fixed it

[BrowneIssue]

Silly?

Silly?

Silly?

Silly?

Yes, my big green scaly friend.

At school we spent a disproportionate amount of time on the origins of some words. As a consequence I still occasionally use some in their old way.

Silly, from 'seely', meaning happy.