Onderwerp: Mysql sending data

Situatie is als volgt:

via mysql processlist zie ik meerdere processen, maar vrijwel allen identiek:
| 576510 | mysqluser | hostname:60645 | mysqldatabase | Query | 0 | Sending data | SELECT * FROM `tablename_posts`
WHERE post_time = 1211307586 |
En dat tig keer; iedere keer als de processlist opgevraagd wordt, staat bovenstaande erin gemeld, waarbij alle gegevens gelijk zijn, op 1 ding na: de post_time is verschillend. Dit gebeurt op slechts 1 database, zelfde dbuser, zelfde table.

Table en database zijn reeds gerepareerd.

Op zich is het "sending data" me wel duidelijk. Enkel begrijp ik niet waarom dit voortdurend te zien is in de processlist. Het zorgt namelijk (vermoedelijk) voor een performance probleem op deze table. Google bood ook weinig aanknopingspunten.

Systeem:
FreeBSD 6.3 release
MySQL: 5.0.45.
Systeem functioneert als database server, geen andere processen.

Waarschijnlijk een zware query?

Normaal gesproken zie je een query ook in je process list, maar is hij dus al zo snel weer uitgevoerd dat je hem niet eens kan zien in je lijst. Of de website heeft dus zoveel requests dat de server DB het niet aankan, maar waarschijnlijk is het gewoon slecht geprogrammeerd.

Overigens raar dat die gast dus z'n posts ophaalt a.h.v. van de post_time.. normaal gesproken haal je dat op a.h.v. je primary key waar je dus ook makkelijk een index op aan kan leggen.

Achtergrond info: het betreft hier een gratis forumhostingsysteem. Daarbij wordt volautomatisch een phpBB3 forum aangemaakt.

Oorspronkelijk geplaatst door RedoX

Waarschijnlijk een zware query?

Voor zover ik vermoed niet, maar dat zou op andere databases en tables ook voor moeten komen.

Code:

# Time: 080829 18:05:22
# User@Host: dbuser[dbuser] @ hostname [IP adres]
# Query_time: 3  Lock_time: 0  Rows_sent: 23991  Rows_examined: 120945
SELECT distinct(p.topic_id) , p.forum_id, p.post_time, p.post_subject, p.post_text, p.bbcode_bitfield, p.bbcode_uid,
                u.user_id, u.user_email, u.username, u.user_allow_viewemail,
                t.topic_title, f.left_id, f.right_id, t.topic_replies as aantal_posts
            FROM `tablename_posts` p JOIN `tablename_users` u on p.poster_id = u.user_id JOIN `tablename_topics` t on p.topic_id = t.topic_id JOIN `tablename_forums` f on p.forum_id = f.forum_id
            ORDER BY p.post_time DESC;

Oorspronkelijk geplaatst door RedoX

Of de website heeft dus zoveel requests dat de server DB het niet aankan, maar waarschijnlijk is het gewoon slecht geprogrammeerd.

Dan zou je het ook weer op willekeurige, andere fora, databases en tabellen moeten zien, lijkt me. Het forum is niet bijzonder qua bezoek, of statistieken.

Weird, ik krijg er de vinger niet achter

Oorspronkelijk geplaatst door ®on

via mysql processlist zie ik meerdere processen, maar vrijwel allen identiek:
| 576510 | mysqluser | hostname:60645 | mysqldatabase | Query | 0 | Sending data | SELECT * FROM `tablename_posts`
WHERE post_time = 1211307586 |

Staat er nog een ander type query die betrekking heeft op dezelfde tabel in de lijst?
Kan zijn dat ie op het vrijgeven van een lock wacht.

Table en database zijn reeds gerepareerd.

De structuur van de tabel zag er na het repareren nog steeds hetzelfde uit als bij de andere forums?
Alle indices zitten er nog steeds op?

Eventueel kan je nog een mysqldump/restore van de tabel proberen, om er zeker van te zijn dat de db bestanden niet corrupt zijn.

===

Overigens raar dat die gast dus z'n posts ophaalt a.h.v. van de post_time.. normaal gesproken haal je dat op a.h.v. je primary key waar je dus ook makkelijk een index op aan kan leggen.

Bij phpbb zit er ook een index op post_time.
Wordt voor zaken als "view posts since last visit" gebruikt.

Oorspronkelijk geplaatst door maxnet

Eventueel kan je nog een mysqldump/restore van de tabel proberen, om er zeker van te zijn dat de db bestanden niet corrupt zijn.

Hmm, dat is wel een idee! Thanks voor de suggestie.

Oorspronkelijk geplaatst door ®on

Achtergrond info: het betreft hier een gratis forumhostingsysteem. Daarbij wordt volautomatisch een phpBB3 forum aangemaakt.


Voor zover ik vermoed niet, maar dat zou op andere databases en tables ook voor moeten komen.

Code:

# Time: 080829 18:05:22
# User@Host: dbuser[dbuser] @ hostname [IP adres]
# Query_time: 3  Lock_time: 0  Rows_sent: 23991  Rows_examined: 120945
SELECT distinct(p.topic_id) , p.forum_id, p.post_time, p.post_subject, p.post_text, p.bbcode_bitfield, p.bbcode_uid,
                u.user_id, u.user_email, u.username, u.user_allow_viewemail,
                t.topic_title, f.left_id, f.right_id, t.topic_replies as aantal_posts
            FROM `tablename_posts` p JOIN `tablename_users` u on p.poster_id = u.user_id JOIN `tablename_topics` t on p.topic_id = t.topic_id JOIN `tablename_forums` f on p.forum_id = f.forum_id
            ORDER BY p.post_time DESC;

Dan zou je het ook weer op willekeurige, andere fora, databases en tabellen moeten zien, lijkt me. Het forum is niet bijzonder qua bezoek, of statistieken.

Weird, ik krijg er de vinger niet achter

Een query waarbij bijna 24000 rijen moeten worden overgepompt, is ook niet erg handig overigens. Dat is echt nooit nodig tenzij het van een cronjob oid afkomstig is. Bovenstaande query kan makkelijk op 500 rijen gelimiteerd worden, tenzij iemand echt de laatste 24000 posts op 1 pagina wil zien.
Kijk eens met een tooltje zoals http://rackerhacker.com/mysqltuner/ of je mysql buffers en cache nog wel groot genoeg is of dat daar iets aangepast moet worden. Eventueel kun je nog kijken of je netwerkbuffers groot genoeg zijn en eventueel verhogen.

Oorspronkelijk geplaatst door systemdeveloper

Een query waarbij bijna 24000 rijen moeten worden overgepompt

Ik denk dat ik het al heb: het aantal rijen matched met het aantal postings op het betreffende forum. Logisch eigenlijk, want het betreft de postingstable. Dat ik er niet eerder bij stil gestaan heb. Volgens mij zit er bij een user iets niet helemaal goed.