6 ms·

Not sure what issues you're seeing, but we have people running this in production at significant scale. One of the issues you linked to was for 0.9.6. Others w

by pauldix 11y ago

Not sure what issues you're seeing, but we have people running this in production at significant scale. One of the issues you linked to was for 0.9.6. Others were there because they had super high tag cardinality and not enough memory to actually run. When people post comments like "I have 50 million series and it crashes on my box with 2GB of memory!!!", they're not relevant. You shouldn't expect miracles...

cantbackup 11y ago
How about issues like these? https://github.com/influxdata/influxdb/issues?utf8=&q=is%3Aopen+label%3Apanic+backup https://github.com/influxdata/influxdb/issues?utf8=&q=is%3Ao... In my case I had a 0.9.4 influxdb setup fed by statsd for about a week. The server hard crashed the first time I tried to back it up.
- pauldix 11y ago
  We just have to close those out. Those are all fixed in the release we have today.
kev009 11y ago
No, and you're countering rhetoric with rhetoric so here are the specs: bare metal 96G RAM, 16 cores, 36 disks (also tried 36 SSDs). Nothing exotic, and something similar you should be using to test before releasing another ill-fated storage engine based on "It works on my Macbook Pro with an artificial load test, ship it!". On the same box carbon is usable, and TSDB can scale linearly across a cluster of these machines. Influx burns down as soon as more than a few GB of metrics are persisted even after backing off collection.
- pauldix 11y ago
  I'm not quite sure what you're doing. If you have that level of hardware I don't know why you're running out of memory. Our tests with 100B points split across 1M series ran on much more modest hardware than that and didn't have a problem. There's something different with what you're doing than with what we're testing. If you can give more detail about what your actual data looks like, I may be able to help. Are you doing this on v0.10 (beta1 or greater) and you're seeing this problem?
  - kev009 11y ago
    I don't have a lot of time to spare on this and we've found a viable option so I won't be using influx any time soon. I can help you with access to my production system if you are interested and as you are watching arrange for between 1k and 10k hosts (for 2 - 20 values per second)
    - monkpit 11y ago
      I'm sad that pauldix disappears when the comments get direct like this - I've used influxdb at smaller scales and I'm genuinely curious to see responses to a few different threads going on in this discussion. But they are left without a reply as of now.
      - pauldix 11y ago
        I disappeared because I can't spend all evening responding to every person on the internet that may be having trouble with our software. An offer to SSH into a system that isn't running Influx and trying to troubleshoot some ambiguous problem isn't direct. We have people that have given us useful troubleshooting information that we've helped (and have helped us improve InfluxDB). Constructive criticism with an offer to help us improve is the best. While I'd love to trace down every problem for everyone on the internet, my time on this planet is limited. As for your concerns about if it scales, we'll try to put out more benchmarks and test code over the coming weeks. For reference, we built a tool for stress testing that you can see here: https://github.com/influxdata/influxdb/tree/master/cmd/influx_stress https://github.com/influxdata/influxdb/tree/master/cmd/influ... You'll have to make your own decisions.
        kev009 11y ago
        We would install Influx, as a go app that is fairly trivial and it speaks the same collection protocol... As a random problem on the internet, this is the workload you should expect from any midsize business and probably something your company would like to target for revenue. Good luck.
      - 11y ago

by pauldix 11y ago

cantbackup 11y ago

How about issues like these? https://github.com/influxdata/influxdb/issues?utf8=&q=is%3Aopen+label%3Apanic+backup https://github.com/influxdata/influxdb/issues?utf8=&q=is%3Ao... In my case I had a 0.9.4 influxdb setup fed by statsd for about a week. The server hard crashed the first time I tried to back it up.

pauldix 11y ago
We just have to close those out. Those are all fixed in the release we have today.

kev009 11y ago

No, and you're countering rhetoric with rhetoric so here are the specs: bare metal 96G RAM, 16 cores, 36 disks (also tried 36 SSDs). Nothing exotic, and something similar you should be using to test before releasing another ill-fated storage engine based on "It works on my Macbook Pro with an artificial load test, ship it!". On the same box carbon is usable, and TSDB can scale linearly across a cluster of these machines. Influx burns down as soon as more than a few GB of metrics are persisted even after backing off collection.

pauldix 11y ago
I'm not quite sure what you're doing. If you have that level of hardware I don't know why you're running out of memory. Our tests with 100B points split across 1M series ran on much more modest hardware than that and didn't have a problem. There's something different with what you're doing than with what we're testing. If you can give more detail about what your actual data looks like, I may be able to help. Are you doing this on v0.10 (beta1 or greater) and you're seeing this problem?
- kev009 11y ago
  I don't have a lot of time to spare on this and we've found a viable option so I won't be using influx any time soon. I can help you with access to my production system if you are interested and as you are watching arrange for between 1k and 10k hosts (for 2 - 20 values per second)
  - monkpit 11y ago
    I'm sad that pauldix disappears when the comments get direct like this - I've used influxdb at smaller scales and I'm genuinely curious to see responses to a few different threads going on in this discussion. But they are left without a reply as of now.
    - pauldix 11y ago
      I disappeared because I can't spend all evening responding to every person on the internet that may be having trouble with our software. An offer to SSH into a system that isn't running Influx and trying to troubleshoot some ambiguous problem isn't direct. We have people that have given us useful troubleshooting information that we've helped (and have helped us improve InfluxDB). Constructive criticism with an offer to help us improve is the best. While I'd love to trace down every problem for everyone on the internet, my time on this planet is limited. As for your concerns about if it scales, we'll try to put out more benchmarks and test code over the coming weeks. For reference, we built a tool for stress testing that you can see here: https://github.com/influxdata/influxdb/tree/master/cmd/influx_stress https://github.com/influxdata/influxdb/tree/master/cmd/influ... You'll have to make your own decisions.
      - kev009 11y ago
        We would install Influx, as a go app that is fairly trivial and it speaks the same collection protocol... As a random problem on the internet, this is the workload you should expect from any midsize business and probably something your company would like to target for revenue. Good luck.
    - 11y ago