-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[0.9.3-rc2] Unable to query influxdb #3607
Comments
@shilpisharma what version of Influxdb are you running? And what does the query you tried to run look like? |
InfluxDb version: 0.9.1
|
@shilpisharma -- what is coming back when you issue these queries? |
No response. The DB just hangs. |
@shilpisharma can you provide log output and a sample write statement? What exactly do you mean by "the DB just hangs"? Is the process up and not responsive? Is it issuing 500s? Will the database process writes? |
Process remains up, but no response. Where will I find the logs for this? |
Look in The process is running according to a process list, but submissions to the write and query endpoints return nothing? Can you paste the results of |
I checked logs, they don't display the query at all.
RAM usage by influx was pretty high due to which server itself became slow. I executed: following command after show measurements:
|
Any suggestions? |
I would suggest waiting for the 0.9.3 release and upgrading. Nothing in your logs is indicative of a problem, and I can't understand why the query endpoint stops responding. Can you provide a sample of your write statements? |
Data was written using rest api through python: for ts in ts_data: |
Thanks, @shilpisharma but that doesn't give me the exact syntax of the writes. Is there a way you can paste in the result of that code running, and give an example of the actual write made? |
Logs during the write:
Records inserted are something like this: Example of one record.
|
@shilpisharma it looks form your write that you are using the deprecated JSON protocol for writes. I would strongly suggest updating your code to use the line protocol as the JSON protocol will be removed in an upcoming release. it is known to cause performance issues, especially if you aren't batching writes. |
Check out https://github.com/influxdb/influxdb-python for writes, I believe that is updated to the latest in 0.9 |
I'm also seeing this problem. When on 0.9.3pre (current master), it hangs on the query endpoint (I do see a ping that gets a 204 when I launch the CLI) with no logging. But when I go back to 0.9.2pre I get symptoms similar to #3632. The workaround there is no help.
The workaround in the other issue (explicitly setting the hostname, to either 127.0.0.1, or localhost) is no help. After that any write returns a 500, but I can query data. Halp! |
I just reproed on the 0.9.3-rc2 build. What can I provide to help debug this? My log looks like:
After that ping in the log, I tried a |
@ccutrer I think you are seeing a different problem than @shilpisharma. I would recommend deleting your |
@beckettsean I stopped influx, deleted the meta dir (I didn't know that was safe!?), and started influx. Same symptoms:
|
@ccutrer in a single node cluster that fully settled before shutdown deleting I have no theories why the service isn't starting cleanly. @shilpisharma any updates from you? |
So um, yeah, deleting |
@ccutrer My apologies for the Given that the deletion fixed the issue, and that we cannot reproduce this here, any ideas how to reproduce the error you were seeing? |
#3836 may help the slow query issue. You may have a lot of series based on the number of points you've written if each point also has 10 tags and a lot of different values. The slow startup is likely due to the shard index loading. You can monitor IO w/ |
A small tidbit - with my original meta directory, and 0.9.3-rc2, and enabling
also, to @jwilder - my iostat output mostly looks like
|
Ok. So loading the index is not the issue. What does your |
@beckettsean it's okay about the meta. I've got a full back of /var/opt/influxdb from 0.9.2pre that I keep copying over. I was last able to write data to it about 48 hours ago (I've got my incoming data going to flat files of the line protocol data for now). Anyhow, after I delete meta, and For @jwilder, I have a total of four measurements and not too many series:
The power,circuit=outside series has one point per second. All other series are one point per minute. It's been going for a month or two. meta/peers.json is |
@ccutrer Don't delete
For In |
@jwilder: nope still hangs with 0.9.3-rc2 after a fresh restore when I either change the meta/peers.json to be |
One other idea to try:
That should start |
Nope, still hangs.
|
@ccutrer That log looks better. What is hanging? The |
The show databases call (or any other query) hangs. |
When the server is hung, can you send a On linux, The full trace in a gist would be very helpful. |
Definitely a deadlock in the metastore. Can you try disabling the Precreation service to see if that resolves it? In your config, set
|
Nope, still hangs: https://gist.github.com/ccutrer/4c225d07535291ad41ce |
@ccutrer - this is a single-node system, correct? |
Correct. |
@ccutrer Would you be able to send your |
@ccutrer Can you try disabling continuous queries?
|
you mean enabled = false. and yes!! I can query!!! and I can write data! and it's not doubling things (a recent bug fix that I tried to update for and caused this whole issue)! |
Yes... sorry. |
The interaction of continuous query service, the meta-store loading and initializing raft state, and syncing node info could cause a deadlock in some instances. There was an extra read-lock taken by isLeader() when it already had a read-lock. Removing this extra lock fixes the startup deadlock. Fixes #3607
The interaction of continuous query service, the meta-store loading and initializing raft state, and syncing node info could cause a deadlock in some instances. There was an extra read-lock taken by isLeader() when it already had a read-lock. Removing this extra lock fixes the startup deadlock. Fixes #3607
Confirmed that with 0.9.3 final I don't need to disable continuous queries to avoid deadlocks. Thanks! |
The interaction of continuous query service, the meta-store loading and initializing raft state, and syncing node info could cause a deadlock in some instances. There was an extra read-lock taken by isLeader() when it already had a read-lock. Removing this extra lock fixes the startup deadlock. Fixes influxdata#3607 (Cherry-picked from 0286a3e)
Hi,
We are doing feasibility testing.
We inserted 35 million records in one of the measurements. But now influx is not responding when we query the table.
Can someone please suggest what can be done?
Shilpi
The text was updated successfully, but these errors were encountered: