And don't kill replication when you see a big time in processlist. > therefore the time get accumulated ?? Each query stands alone in timing. The "idle" time is caught by wait_timeout, which was already mentioned. You can distinguish the cases by whether processlist says "Sleep".
A Sleeping thread is virtually harmless. * It is occupying some RAM for the thread (usually not an issue); * If there are too many, you could hit max_connections, thereby disallowing new connections. See Percona -- they have some user statistic features that are on beyond the MySQL offerings. > -----Original Message----- > From: walter harms [mailto:wha...@bfs.de] > Sent: Monday, July 23, 2012 9:31 AM > To: mysql@lists.mysql.com > Subject: Re: restrict Connect Time > > > > Am 23.07.2012 17:38, schrieb Reindl Harald: > > > > > > Am 23.07.2012 17:35, schrieb walter harms: > >> > >> > >> Am 23.07.2012 16:58, schrieb Ananda Kumar: > >>> so. its more of inactive connections, right. > >>> What do you mean by NEVER LOGOUT > >>> > >> > >> The programms watch certain states in the database, the connect > >> automatic at db startup, disconnecting is an error case. > > > > so why do you want to restrict connect time if this is a error-case > > for you? > > > > no, this is a misunderstanding, > i want to catch "running" querries that already run longer than a > certain time. When i use my simple approach like: > select * from information_schema.processlist where state like > 'executing' and time > 1000 ; it did work work as intended. > > Unfortunately 'time' is cumulative meaning there is a real risk > catching legitimate users. I guess i could filter it based on 'info' > (what contains the query) but i was hoping that there is a more simple > way. > > re, > wh > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
