Hello,
I followed instructions from github to monitoring GPU.
Everything is fine, except one thing: i cannot retrieve data when using group by time() command.
Here is my data:
Its work correctly when I use NOAA_water_database.
I’m using ubuntu 18.04 LST and Influxdb 1.7.9.
Thanks,
Can you post the query you are running?
have you passed a time range as parameter?
SELECT {...} GROUP BY time(5m)I used
SELECT max(“Memory Utilization”) FROM gpuseries WHERE time >= now() - 30m GROUP BY time(200ms), “GPU” fill(none)
I’m sure that
SELECT max(“Memory Utilization”) FROM gpuseries WHERE time >= now() - 30m
return results.
I tried to use
SELECT max(“Memory Utilization”) FROM gpudb.standard.gpuseries WHERE time >= 1578907604s and time <= 1578907658s group by time(200ms)
and it’s work…
The query itself is syntactically correct and should run without problems.
I ran a query similar to yours (using chronograf)
SELECT mean("cpu_time_ms") AS "mean_cpu_time_ms" FROM "monitoring"."SqlServer"."sqlserver_requests" WHERE time > :dashboardTime: AND ("sql_instance"='SQLCSRV04:xxx:') GROUP BY time(200ms), "sql_instance" FILL(previous)
Since you just say that it returns no results (and does not return any error) I think the problem is the very small time unit in the GROUP BY time(200ms).
By grouping by such a small time unit, you will force the result to that precision, but if no data are available for 1 second you will get 5 empty rows in the output. If you don’t have any point for several time ranges you will get a huge amount of empty rows, that will make your result look empty
I will write a pseudo-data example: (with readable time)
time | value
20190113 9:00:00.000 | 12
20190113 9:00:00.230 | 10
20190113 9:00:00.510 | 12
20190113 9:00:00.630 | 13
20190113 9:00:02.100 | 10
20190113 9:00:02.420 | 12
If you execute whis
SELECT max(value) FROM __ WHERE time >= 20190113 9:00:00 AND time <= 20190113 9:00:03 GROUP BY time(200ms)
you will get something like this:
20190113 9:00:00.000 | 12
20190113 9:00:00.200 | 10
20190113 9:00:00.400 |
20190113 9:00:00.600 | 12
20190113 9:00:00.800 | 13
20190113 9:00:01.000 |
20190113 9:00:01.200 |
20190113 9:00:01.400 |
20190113 9:00:01.600 |
20190113 9:00:01.800 |
20190113 9:00:02.000 | 10
20190113 9:00:02.200 |
20190113 9:00:02.400 | 12
20190113 9:00:02.600 |
20190113 9:00:02.800 |
20190113 9:00:03.000 |
As you can see, since I don't have data for each interval (of 200ms) I get a lot of empty points.
Your result probably looks empty because in your WHERE you are specifying a range, in which you have no data (at the beginning), thus causing a huge amount of empty points to be outputted in the result.
ie, if I ran the following on my sample data:
WHERE time >= 20190113 8:50:00 AND time <= 20190113 9:00:03
the output will have 10min (from 8:50:00 to 9:00:00) of empty data, if I group by 200ms it will translate to 3000 empty points at the beginning of the result set).
the result may look empty even if it’s not.
I suggest you find a time unit compatible with your data gathering frequency.
Also using a different value in the fill() function (like fill(previous) ) may help you to obtain a more meaningful/readable dataset
Thank for your reply,
But it’s seem because of mismatch time
I collected data from 9 a.m and in 4 p.m, i’m back and the data show up. My time zone is GMT +7.
Do you know how to configure this ?
Thank for helping xD
You can add tz() at the end of the query
SELECT ... FROM ... GROUP BY ... fill(null) tz('Europe/Rome')
See:
- [Docs](https://docs.influxdata.com/influxdb/v1.7/query_language/spec/#select)
- [Github issue](https://github.com/influxdata/docs.influxdata.com/issues/1153) for additional documentation
- [list](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List) of supported timezones on wikipedia
There are some bugs related to the timezone, try it yourself and see if it works.
Another option is to add an offset of N hours to the query in the where clause.
The timezone "issue" is often solved by the frontend tools, which allow you to choose the timezone and filter the time range accordingly
