•  

Announcement

Announcement Module
Collapse
No announcement yet.

18446744073709.550781

Page Title Module
Move Remove Collapse
Conversation Detail Module
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts

  • 18446744073709.550781

    #1
    I'm trying to use the more accurate query time logging available in percona server (5.1.47-rel11.2-log (Percona Server (GPL), 11.2 , Revision 53)). However, the slow query log often contains entries like this:

    # Time: 100810 7:55:04# User@Host: db[db] @ [172.30.2.30]# Thread_id: 28056 Schema: mydb Last_errno: 0 Killed: 0# Query_time: 18446744073709.550781 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 Rows_affected: 0 Rows_read: 1# Bytes_sent: 11 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0# No InnoDB statistics available for this querySET timestamp=1281423304;SET autocommit=0;


    That query duration looks like 2^64, so it's probably really 0, so this query shouldn't be logged at all. I've done a little searching and all I've found is others having the same problem. Where is this bug?
    Tags: None

  • #2
    http://www.mysqlperformanceblog.com/2009/05/17/what-time-184 46744073709550000-means/

    Comment


    • #3
      That's interesting, but for me it renders the slow query log useless and thus I can't use tools like mk-query-digest. I get this number for about 75% of all entries in the slow query log, all for queries that shouldn't be logged at all. This very low-level bug is propagating through several layers that could easily trap it. I also suspect that it's also just wrong since the number never varies.
      In some ways it's good since it means that my queries are extremely short!
      That article mentions that the absolute accuracy doesn't really matter that much, though I really would like the recorded value to be at least within a couple of million years of the actual time. Why not use the system clock that's probably good for 100ths of a second and not subject to multi-cpu problems?

      Comment


      • #4
        mk-query-digest will ignore the value if it is larger than, by default,

        --attribute-value-limit 4294967296

        And use the last-seen value instead. (Yes, that's an inaccuracy, but it seems like the best compromise.)

        The server can't use gettimeofday() because the cost is way too high.

        Comment

        Working...
        X