View Full Version : QNAP TS101 and SS6.5.. .time for a Branch?
roamingstudio
2006-10-10, 02:06
Ive been reading through threads elsewhere on the forum and there are a couple of interesting issues which seem to be appearing in the beast of 6.5...
1) 6.5 needs MySQL. This appears to be a bit of a beast / memory eater. It works on the installations of the Synology (also 64mb) stuff - but then MySQL is designed into their firmware; it is not in QNAP by default. The Synology version may therefore be a better one to use than the standard MySQL flavour... we should ask FlipFlip.
2) Some people report what appear to be memory leaks in the windows flavour of SS. If leaking is occuring on the SS then overtime more and more page file will be required- spin down may not occur.
3) There appear to be large caches generated on some machines which need to be cleaned periodically. It is unclear why these caches are appearing; but they are eating hard disk. This may or may not be occuring on the QNAP - check the cache sizes if you can.
The decision to move to MySQL has provoked some negative reactions elsewhere; but is a design choice made from the perspective of SS working on machines with good memory (Windows and such like). One writer remarked that over time MySQL will provide faster user response; more dynamic updates etc; but trying to generate code for all database versions will be problematic etc.
Therefore would the community be willing to look at developing a SS branch which features most of the 6.5 functionality but still uses the old style SQLite databases (or another SQL varient but without the memory issues)?
Thoughts?
Some of the problem might be that there is a lot more functionality (e.g. Transporter support) in 6.5 compared to 6.3 - so the issues might be a combination of 6.5 & MySql and not just MySql vs SQLite.
I think it would be worthwhile to look
1. What functionality of 6.5. is missing in 6.3 for the NAS community (e.g. Transporter support)
2. What is the target minimum processorspeed /memory footprint of such a branch (e.g. NSLU2 - 32Mbytes , TS-101/ DS-106 / Linkstation 64Mbyte, TS-201/DS-106x / KuroBox - 128Mbyte)
Has anybody ever tried to fine tune the MySQL configuration? Maybe it could be tweaked to use a little less memory?
That's a good point - I have got 6.5 running on a FSG3 (266MHz ARM processor 64Mbyte) and except for web interface - it runs OK and memory usage isn't excessive but my library isn't large.
Memory seems to be the issue but there has been no analysis done so that we can be sure effort is applied to the areas that will yield most benefits.
For example:
1. What is the memory usage of 6.3 vs 6.5 for the same library at startup and after 1 day use ?
3. What effect does library size have on memory usage ?
3. Does use/activity have an effect on memory usage (e.g. cache / Perl garbage collection)
4. Do some or any of the new plugins use chunk of memory ?
5. Is there evidence of a memory leak ?
roamingstudio
2006-10-10, 02:57
Good points above. The main problem is that currently the QNAP install is done by Progressive AV in the UK; any tweaking requires a bit of technical knowledge to understand what is happening.
We are currently working on opening this up so that others can try this as the QNAP is a nice platform.
Jerryacg
2006-10-10, 03:21
That's a good point - I have got 6.5 running on a FSG3 (266MHz ARM processor 64Mbyte) and except for web interface - it runs OK and memory usage isn't excessive but my library isn't large.
Memory seems to be the issue but there has been no analysis done so that we can be sure effort is applied to the areas that will yield most benefits.
For example:
1. What is the memory usage of 6.3 vs 6.5 for the same library at startup and after 1 day use ?
3. What effect does library size have on memory usage ?
3. Does use/activity have an effect on memory usage (e.g. cache / Perl garbage collection)
4. Do some or any of the new plugins use chunk of memory ?
5. Is there evidence of a memory leak ?
re 3. Mav had his QNAP spinning down, before he loaded up his QNAP, so this maybe an issue.What we need is someone who has upgraded to 6.5, but as yet not begun to fill up the hardrive. re 4.My experience is that the 6.5 let my QNAP spin down only once. Before I loaded the all in one plug in update. So again, this maybe a factor.
Jerry
1. What functionality of 6.5. is missing in 6.3 for the NAS community (e.g. Transporter support)
I might have misunderstood, but we can't assume that NAS ownership and Transporter ownership are mutually exclusive states. I have a Qnap and my Transporter is on order.
My experience is that the 6.5 let my QNAP spin down only once. Before I loaded the all in one plug in update. So again, this maybe a factor.
It might be Jerry, but unfortuantely not in isolation. I've loaded the all-in-one update for 6.5 and my Qnap still spins down. From memory, I think my database contains about 3200 tracks, 99% of which are FLAC.
Has anybody ever tried to fine tune the MySQL configuration?
Bad news: I've googled around a bit. One report about MySQL optimization is starting with the following statement:
"First off, InnoDB requires about 10 megs of memory to run, so disable it." - but InnoDB is exactly what SlimServer requires. On my system I've seen memory consumption of about 18M after a few days. Assuming 10M for InnoDB there doesn't seem to be much left...
On NSLU2/ UNSLUNG the precompiled version of MySql does not have InnoDB compiled and yet 6.5 seems to work. See post 15 onwards for the discussion
http://forums.slimdevices.com/showthread.php?t=26723&page=2
roamingstudio
2006-10-10, 04:10
This is why im thinking that the MySQL has lots of nice features; and makes a lot of sense... but using it sort of closes the end for the 'slim' server products... they tend to become 'thin server clients' in a 'thin body' but still require more ram etc.
I know in the world of Subversion (repositories) they resisted the temptation of the Berkley DB; and went for a FSFS system (http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.reposadmin.basics.backends.bdb). One of the issues was that SQL uses a thread to consistently check database for corruption; and FSFS was felt to be better. Subversion is still FAST...
On NSLU2/ UNSLUNG the precompiled version of MySql does not have InnoDB compiled and yet 6.5 seems to work.
...and so does it on Windows: I replaced "innodb" in my.tt with "skip-innodb" and restarted SlimServer. It's still scanning, but it's running with a footprint almost 9M smaller than before (6 instead of 15M).
I have no experience with this configuration (and don't plan to use it that way). So do this at your own risk :-)
Powered by vBulletin® Version 4.1.12 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.