Opened at 2008-02-28T12:17:37Z
Last modified at 2010-01-07T00:52:21Z
#325 new defect
flogtool scalability/performance
Reported by: | zooko | Owned by: | warner |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | operational | Version: | 0.8.0 |
Keywords: | logging scalability performance memory | Cc: | |
Launchpad Bug: |
Description
I'm trying to diagnose problems on the current tahoe production grid, and here are some observations:
- The logs.pickle file is 2 GB in size, and can't be web-viewed as flogtool web-viewer logs.pickle eventually dies after running out of RAM.
- 7zipping logs.pickle takes 15 minutes and results in a logs.pickle.7z of 115 MB. (I chose 7zip because I didn't want to use up too much CPU on the tahoe production grid server, and 7zip is one of the most CPU-efficient among the compressors that also give good ratio on a large file.)
- flogtool dump logs.pickle &> logs.dump.txt on my Macbook Pro takes 30 minutes and results in a logs.dump.txt of size 415 MB.
So for even a little-used and small grid like the current tahoe production grid, flogtool has some scalability/performance problems.
By the way, in order to estimate how much redundancy there is in the resulting text log file compared to the pickle, I 7zipped the logs.dump.txt, which resulted in a logs.dump.txt.7z of size 40 MB.
Change History (4)
comment:1 Changed at 2008-03-13T17:02:13Z by zooko
- Owner changed from nobody to warner
comment:2 Changed at 2008-06-01T21:03:15Z by warner
- Milestone changed from eventually to undecided
comment:3 Changed at 2009-03-08T22:06:14Z by warner
- Component changed from unknown to operational
comment:4 Changed at 2010-01-07T00:52:21Z by davidsarah
- Keywords logging scalability performance memory added
Note: See
TracTickets for help on using
tickets.