When trying to put some date into InfluxDB (1.7.3) I am getting error that max-series-per-database is reached:
(“error”:“partial write: max-series-per-database limit exceeded: (1000000) dropped=2")
Meanwhile show series exact cardinality for specific database shows that there are just around 510 000 entries.
Also select count(*) from database gives same result
Any idea I am getting error that max series per database is reached?
upd:
I am using open source version of InfluxDB without clustering
show series cardinality show almost the same result what exact cardinality does
Try increasing max-series-per-database configuration option and see if the error persists.
If you are using enterprise clustering, the exact cardinality may only count series on one region server, while another has the rest 490k series.
Are there other retention policies in the same database?
Also note, that error may be generated based on approximate cardinality.
Related
With InfluxQL, the following query shows you the overall series cardinality of the database.
SHOW SERIES CARDINALITY
How can I see the series cardinality of a single measurement? Or even better, all the measurements in a database with their respective cardinalities, as a list?
I am using InfluxDB 1.7.2.
I wasn't expecting it to be that simple but it turns out the query below works.
SHOW SERIES CARDINALITY FROM <some_measurement_name>
Grafana does not display any data ( failed to fetch ) after 60s for large datasets but when the interval is smaller dashboard loads fine any help here?
Tried tweaking timeouts in grafana.ini does not seem to help here looks like Grafana has a hard - limit on those parameters
Grafana version > 7.0.3
Data source : influxdb
dashboard loads fine for smaller intervals
any help here would be appreciated here?
Use time groupping GROUP BY time($__interval) in your InfluxDB query - https://grafana.com/docs/grafana/latest/datasources/influxdb/#query-editor - Grafana already has macro $__interval which will select "optimal" time aggregation based on current dashboard time range.
It doesn't make sense to load huge datasets with original granularity. You may solve it on the Grafana level somehow, but then you may have a problem in the browser - it may not have so much memory or it will take ages.
We are measuring throughput using Grafana and Influx. Of course, we would like to measure throughput in terms how many requests, approximately, happens every single second (rps).
The typical request is:
SELECT sum("count") / 10 FROM "http_requests" GROUP BY time(10s)
But we are loosing possibility to use astonishing dynamic $__interval that very useful when graph scope is large, like a day of week. When we are changing interval we should change divider into SELECT expression.
SELECT sum("count") / $__interval FROM "http_requests" GROUP BY time($__interval)
But this approach does not work, because of empty result returns.
How to create request using dynamic $__interval for throughput measuring?
The reason you get no results is that $__interval is not a number but a string such as 10s, 1m, etc. that is understood by influxdb as a time range. So it is not possible to use it the way you are trying.
However, what you want to calculate is the mean which is available as a function in InfluxQL. The way to get the behavior that you want is with something like this.
SELECT mean("count") FROM "http_requests" GROUP BY time($__interval)
EDIT: On a second thought that is not quite what you want.
You'd probably need to use derivative. I'll come back to you on that one later.
Edit2: Do you think this answers the question that you have Calculating request per second using InfluxDB on Grafana
Edit3: Third edit's a charm.
We use your starting query and wrap it in another one as such:
SELECT sum("rps") from (SELECT sum("count") / 10 as rps FROM "http_requests" GROUP BY time(10s)) GROUP BY time($__interval)
Is there a limit for table rows in additional databases in abas erp?
If there is a limit: On which factor the limit is based, how can I calculate the limit and what happens if I try to add more lines by GUI, FO or EDP/EPI?
Can I find it documented in the abas online help? I haven't.
Yes there is a limit, which is unfortunately not customizable.
You can see a full list of know limitations under help/hd/html/49B.1.4.html
In your specific case the limit of lines in additional databases is 65535.
If you reach the limit, the abas core will show an error message and terminate your current FOP. You can (and should) get the current amount of lines by evaluating the variable tzeilen (currTabRow)
In this case I'm also not aware of any other than the one you mentioned, but you can query ozeilen in a selection list (for master files, not for i.e. sales and purchasing because the rows there aren't physically 'rows'). tzeilen (currTabRow) is buffer related.
For my case, I need to capture 15 performance metrics for devices and save it to InfluxDB. Each device has a unique device id.
Metrics are written into InfluxDB in the following way. Here I only show one as an example
new Serie.Builder("perfmetric1")
.columns("time", "value", "id", "type")
.values(getTime(), getPerf1(), getId(), getType())
.build()
Writing data is fast and easy. But I saw bad performance when I run query. I'm trying to get all 15 metric values for the last one hour.
select value from perfmetric1, perfmetric2, ..., permetric15
where id='testdeviceid' and time > now() - 1h
For an hour, each metric has 120 data points, in total it's 1800 data points. The query takes about 5 seconds on a c4.4xlarge EC2 instance when it's idle.
I believe InfluxDB can do better. Is this a problem of my schema design, or is it something else? Would splitting the query into 15 parallel calls go faster?
As #valentin answer says, you need to build an index for the id column for InfluxDB to perform these queries efficiently.
In 0.8 stable you can do this "indexing" using continuous fanout queries. For example, the following continuous query will expand your perfmetric1 series into multiple series of the form perfmetric1.id:
select * from perfmetric1 into perfmetric1.[id];
Later you would do:
select value from perfmetric1.testdeviceid, perfmetric2.testdeviceid, ..., permetric15.testdeviceid where time > now() - 1h
This query will take much less time to complete since InfluxDB won't have to perform a full scan of the timeseries to get the points for each testdeviceid.
Build an index on id column. Seems that he engine uses full scan on table to retrieve data. By splitting your query in 15 threads, the engine will use 15 full scans and the performance will be much worse.