Skip to content
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

Prevent exponential growth in ~/.influx_history #5460

Merged
merged 1 commit into from
Jan 27, 2016
Merged

Prevent exponential growth in ~/.influx_history #5460

merged 1 commit into from
Jan 27, 2016

Conversation

adamsvoboda
Copy link
Contributor

This PR addresses issue #5436

Please note that Influx is using the Liner library for the ReadHistory / AppendHistory / WriteHistory functions.

THE PROBLEM:
When the influx console is started, ReadHistory reads the entire buffer from ~/.influx_history into memory, for up to 1000 lines.

Each time a command is entered into the console, AppendHistory is called. This appends to the history buffer we have in memory which has a limit of 1000 entries as well. So far, so good.

Now things start to get hairy. WriteHistory is called each time a command is entered. Not only does this function ignore the HistoryLimit, but it appends the history buffer in memory to the file. Additionally, when exit() is issued, WriteHistory writes that entire buffer to ~/.influx_history again. You can see how this will cause the file to quickly grow exponentially...

REPRODUCTION
If you want to reproduce the growth yourself:

  1. Clear your ~/.influx_history file
  2. Start influx console and send the exit command.
  3. Start the console again and send the exit command one more time.
  4. Check ~/.influx_history you'll see it contains the exit command six times, instead of twice as expected.

PROPOSED SOLUTION:
On the liner library example page, it looks like they open the historyFile with os.Open (read-only), and then attempt to recreate the file each time using os.Create() before WriteHistory is called. If the file already exists, os.Create() will truncate it. This prevents the growth problem by using WriteHistory as intended.

I modified the file open function for the ReadHistory call and also closed the handle immediately after finished. I didn't see a need to use defer since the handle to the file won't be reused elsewhere.

I've created a function called saveHistory that calls WriteHistory after clearing the ~/.influx_history file. I added historyFilePath to the CommandLine struct to make this easier. I removed historyFile from the struct since it's no longer used. I replaced the calls to WriteHistory with my saveHistory function.

The history file is cleared before WriteHistory is called after each
command/exit() to prevent exponential file growth.

This commit addresses issue #5436, please see PR for full explanation.
@adamsvoboda
Copy link
Contributor Author

I don't feel it's necessary to call saveHistory() each time a command is ran. Only updating the history file on exit() / certain signals (ctrl+c) would probably be ideal, but I'm curious to see how others feel on the subject. I wanted to preserve the original history saving logic, so that's why the call is still there.

This issue was brought to our attention by a user who was piping a lot of data directly into the influx console via a script. I don't know how many people will use the console to do that, but if that's a common scenario then saving the history after each command would introduce unnecessary slowdown due to IO, and that would be why I feel its not necessary. For normal usage, it should be fine.

@toddboom
Copy link
Contributor

@corylanou how's this one look to you?

@corylanou
Copy link
Contributor

+1

@toddboom
Copy link
Contributor

@sczk awesome, thanks! 👍

toddboom added a commit that referenced this pull request Jan 27, 2016
Prevent exponential growth in ~/.influx_history
@toddboom toddboom merged commit 3723680 into influxdata:master Jan 27, 2016
@jwilder jwilder added this to the 0.10.0 milestone Feb 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants