UBB.threads PHP Forum Software Community Forums UBB.threads Bug Reports Generation times and Ubbthreads logo appear in header, not footer - screenshot

I just upgraded from 7.1 to 7.53.

It looks like some bad HTML in your header or footer. Just did a quick test and see a few missing tags in your tables. Couple versions back we changed the layout a bit which doesn't behave quite as nicely with bad HTML in the header/footer.

OK, fixed that.

Here's another head-scratcher:

When folks go to My Stuff and click on their "posts" it brings them all up --- in some cases nine years worth of posts.

How to limit that please?

rb

And this may be related:

LOVE the concept of a search option that allows numerical searches. Unfortunately, when I tried the internal and ran a search for 308 for one year, I locked down the server for over five minutes.

It's unusable here, and I have a pretty hot machine.

Any advice?

You must have had a extremely large number of search results.
Rick did warn us it would be slower on large boards.

What do you have set for "Maximum Results from Search: "
in the control panel?

The guys have been dying for a new search option, as we can't do caliber-specific searches with the mysql search.

The internal works well if you use the advanced, but every time someone just pops open the search box and types in a term, it locks us down. It's unimplementable under these condictions, but would LOVE to hear some tweaks !!!

Guys:

With 7.1, I had no problem with searches. Guys hated that it's not capable of searching three characters and numbers, so I was very glad to see the new internal search option.

Alas, it is not usable. 2:00 am, very few on, figured I'd try internal again, 1 year search for "308" limited to 200 results:

Generated in 330.673 seconds in which 330.623 seconds were spent on a total of 11 queries. Zlib compression enabled.

OUCH!!!!

At least there are results, but of course, I dare not implement it.

Turns out it's just a tease ...

Unfortunately for a board your size, the internal option really isn't an option. It has to do a "like" comparison on every post.

Since you're running on a dedicated server you're probably better off modifying the minimum character limit for mysql's fulltext engine. The indexes will have to be rebuilt, so you'd be looking at a bit of downtime to do it however.

http://dev.mysql.com/doc/refman/5.1/en/fulltext-fine-tuning.html

Hmm, an option nonetheless. Thanks for the tip, Rick

Rick I understand how to set the min char limit and the need to re-index.
But I have never seen where you can add numeric searches in the fulltext engine. Granted for use on a dedicated server but I have not figured out how to set numeric string searches to be allowed.

If the number you're searching for is longer than the minimum character limit, then it should just work. For example, doing a fulltext search here, looking for 1234


Comes up with several results, including:

https://www.ubbcentral.com/forums/ubbthreads.php/topics/151140#Post151140
https://www.ubbcentral.com/forums/ubbthreads.php/topics/150457#Post150457

Guys:

I'm still having a lot of trouble with 7.53 since I upgraded last week.

Normally, server load is between 0.10 and 0.50. Then, all of a sudden, load spikes to 3, 4, and this morning at 7:25-7:30 (far from peak time), to 6.20, and generation times to 300-400 seconds.

Here's what the slow query log says:


Here's another at the same time:




I have the mysql search enabled, not internal, I have results limited to 200, and the weird thing is, a week ago when I was still on 7.1, I did not have these spikes. Something happened when I went from 7.1 to 7.53, and now, intermittently, but regularly throughout the day, the board will go from humming along with a very low load to basically being locked down for minutes at a time.

It's feast or famine!

Server is a dual Opteron, 4 GB of RAM, 4 15K RPM SCSI with RAID 10.

I'll take any help I can get. I'm willing to upgrade the server if necessary, but I can't believe that everything was humming along just fine with 7.1 and that 7.53 can't do the same with this server. Something, somewhere is not set right, I suspect, and I appreciate any help you fine folks can provide in helping me ID the problem.

Geez guys, I'm in the middle of a spike, and server load is 34.19!!!!

Here's the current mytop status :

MySQL on localhost (4.1.22-standard-log) up 0+00:53:46 [10:06:38]
Queries: 385.4k qps: 122 Slow: 27.0 Se/In/Up/De(%): 45/02/08/00
qps now: 1 Slow qps: 0.0 Threads: 392 ( 391/ 0) 33/00/00/00
Cache Hits: 132.4k Hits/s: 42.0 Hits now: 0.0 Ratio: 76.1% Ratio now: 0.0%
Key Efficiency: 99.5% Bps in/out: 14.1k/257.3k Now in/out: 321.9/44.8k

Id User Host/IP DB Time Cmd Query or State
-- ---- ------- -- ---- --- ----------
57689 root localhost mysql 0 Query show full processlist
57715 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 2 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t2.USER_TOPICS_PER_PAGE, t2.USE
57714 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 5 Query SELECT USER_TEXT_EDITOR,USER_TOPICS_PER_PAGE,USER_POSTS_PER_TOP
57713 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 9 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t2.USER_TOPICS_PER_PAGE, t2.USE
57711 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 11 Query select t1.TOPIC_ID,t1.POST_ID,t2.USER_DISPLAY_NAME,t1.TOPIC_CRE
57712 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 11 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57710 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 14 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57708 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 15 Query SELECT t.TOPIC_REPLIES, t.TOPIC_VIEWS, t.TOPIC_LAST_REPLY_TIME,
57709 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 15 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57698 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 18 Query select t1.TOPIC_ID,t1.POST_ID,t2.USER_DISPLAY_NAME,t1.TOPIC_CRE
57688 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 20 Query SELECT t2.USER_SHOW_AVATARS, t2.USER_TIME_FORMAT, t2.USER_IGNOR
57661 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 22 Query update ubbt_USERS set USER_SESSION_ID = '98dce83da57b0395e16346
57687 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 22 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t2.USER_TOPICS_PER_PAGE, t2.USE
57662 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 27 Sleep
57669 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 27 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57658 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 29 Query SELECT t.TOPIC_REPLIES, t.TOPIC_VIEWS, t.TOPIC_LAST_REPLY_TIME,
57659 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 29 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57660 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 29 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57656 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 30 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t2.USER_TOPICS_PER_PAGE, t2.USE
57657 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 30 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t2.USER_TOPICS_PER_PAGE, t2.USE
57646 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 32 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57636 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 33 Query SELECT t2.USER_SHOW_AVATARS, t2.USER_TIME_FORMAT, t2.USER_IGNOR
57629 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 35 Query select t1.TOPIC_ID,t1.POST_ID,t2.USER_DISPLAY_NAME,t1.TOPIC_CRE
57618 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 37 Query select t1.USER_DISPLAY_NAME, t3.USER_LAST_VISIT_TIME, t1.USER_P
57613 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 39 Query SELECT t.TOPIC_REPLIES, t.TOPIC_VIEWS, t.TOPIC_LAST_REPLY_TIME,
57614 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 39 Query SELECT t.TOPIC_REPLIES, t.TOPIC_VIEWS, t.TOPIC_LAST_REPLY_TIME,
57611 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 41 Query SELECT t2.USER_SHOW_AVATARS, t2.USER_TIME_FORMAT, t2.USER_IGNOR
57612 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 41 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57609 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 42 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM
57610 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 42 Query SELECT t.TOPIC_REPLIES, t.TOPIC_VIEWS, t.TOPIC_LAST_REPLY_TIME,
57566 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 48 Query SELECT t2.USER_TOPIC_VIEW_TYPE, t1.USER_ID, t1.USER_DISPLAY_NAM

Finally back up. 25-minute gap between postings during the spike.

No more than a two-minute gap for ten consecutive posts on either side of the spike.

This is killing me.

Help please.

OK, and here's what my server admin says:

Rick

We have completed the databases check and tweaked a little more the apache / mysql settings.
The server load is better now and the forum is working, but still a lot of sleep connections to the forum as you can see below :

1163 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 1 Sleep
995 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 2 Sleep
2365 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 2 Sleep
6635 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 3 Sleep
5715 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 4 Sleep
4680 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 5 Sleep
6602 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 5 Sleep
2187 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 6 Sleep
4344 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 6 Sleep
5346 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 6 Sleep
692 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 7 Sleep
4915 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 7 Sleep
5485 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 7 Sleep
5714 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 7 Sleep
3474 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 10 Sleep
4618 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 12 Sleep
3663 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 13 Sleep
5548 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 14 Sleep
6285 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 14 Sleep
6475 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 14 Sleep
3661 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 15 Sleep
5365 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 15 Sleep
6465 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 15 Sleep
5157 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 16 Sleep
640 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 17 Sleep
6415 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 18 Sleep
6391 XXXXXXXXXXXXXXXXXX localhost XXXXXXXXXXXXXXXXXX 19 Sleep

You should really contact UBBThreads about this.

--
Thank you,

I don't believe you need to upgrade the server, as that should be plenty to run what you have. And the only way you're going to benefit from more memory is moving to a 64-bit OS since you already have 4 megs.

The slow queries look like they are definitely causing some issues. Not sure if we've touched on this yet, but the best place to start is with a couple things.

Sas your MySQL server been optimized at all? Also with the number of posts that you have, you probably need to look at the individual tables as well if they haven't been optimized lately.

I'd grab mysqltuner and run it if you haven't done so. This will at least tell you if there are any variables that are severely out of whack and how many of your tables are fragmented.

The sleep connections sounds like you might still be running with persistent connections turned on? You shouldn't be seeing any of those, as when the PHP script finishes executing the connection should close along with the webserver process.

So, if you still have persistent connections turned on, I'd turn them off.

Will do, Rick. Thanks. Will get mysqltuner hooked up asap.

Mysql tuner:

[--] Up for: 2m 0s (17K q [144.108 qps], 2K conn, TX: 37M, RX: 2M)
[--] Reads / Writes: 53% / 47%
[--] Total buffers: 1.1G global + 5.4M per thread (600 max threads)
[!!] Allocating > 2GB RAM on 32-bit systems can cause system instability
[!!] Maximum possible memory usage: 4.3G (107% of installed RAM)
[OK] Slow queries: 0% (0/17K)
[OK] Highest usage of available connections: 1% (7/600)
[OK] Key buffer size / total MyISAM indexes: 900.0M/880.9M
[OK] Key buffer hit rate: 96.2% (212K cached / 8K reads)
[OK] Query cache efficiency: 71.9% (5K cached / 7K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 464 sorts)
[OK] Temporary tables created on disk: 1% (6 on disk / 367 total)
[OK] Thread cache hit rate: 99% (7 created / 2K connections)
[OK] Table cache hit rate: 91% (61 open / 67 opened)
[OK] Open file limit used: 3% (113/3K)
[OK] Table locks acquired immediately: 99% (5K immediate / 5K locks)

Just want to let you know, persistant connections are worthless, and you should never turn them on unless you know enough about the server to be able to highly error check them appropriately and tune accordingly...