| 1 |
William Kenworthy wrote: |
| 2 |
> On 21/07/13 22:31, luis jure wrote: |
| 3 |
>> OK, now i have my system successfully installed and running on my new SSD. |
| 4 |
>> now i have to decide what to do with the rest of the disk (it's a 256MB |
| 5 |
>> samsung). |
| 6 |
>> |
| 7 |
>> the first big question is: what about swap? i found some web pages |
| 8 |
>> (perhaps old) stating that it's not wise to put swap on the SSD because of |
| 9 |
>> all the read/writes. but apparently from what i read on the recent |
| 10 |
>> thread on this list, that shouldn't be much of a concern now. |
| 11 |
>> |
| 12 |
>> i also read somewhere that if you have swap on the SSD and want to avoid |
| 13 |
>> unnecessary read/writes, you can reduce swappiness. i have 12GB RAM and i |
| 14 |
>> think normally i don't really need swap space on disk, so i thought that |
| 15 |
>> could be a good idea. |
| 16 |
>> |
| 17 |
>> so what i'm planning to do now is: |
| 18 |
>> |
| 19 |
>> - put swap on the SSD |
| 20 |
>> - reduce swappiness |
| 21 |
>> - put /var/tmp/portage on tmpfs |
| 22 |
>> |
| 23 |
>> so, do you guys think that's a good setup? |
| 24 |
>> |
| 25 |
> swap: this will make one of the bigger speedups to the system when you |
| 26 |
> need swap. swap is good - yes you can do without it, but the day comes |
| 27 |
> when you REALLY do want it, and ... [crash!] ... otherwise it can just |
| 28 |
> sit there waiting :) |
| 29 |
> |
| 30 |
> /etc/sysctl.conf: |
| 31 |
> |
| 32 |
> #vm.swappiness=1 |
| 33 |
> #vm.vfs_cache_pressure=50 |
| 34 |
> |
| 35 |
> these were recommended to me for running vm's and seem to do the job |
| 36 |
> (usually I am running with a several GB of swap (16G ram, 16G swap) in |
| 37 |
> use ... these settings definitely minimise it though big rsync jobs |
| 38 |
> stall when it fills ram+swap. |
| 39 |
> |
| 40 |
> /var/tmp/portage is a more difficult one ... a long thread way back |
| 41 |
> (Dale, I think you were in it) looking at speed showed there was no |
| 42 |
> speed advantage to compiling in tempfs because spinner) disk caching was |
| 43 |
> so good the data only hit the disk when necessary. I presume the same |
| 44 |
> will apply with compiling and SSD's in that the actual writes will be |
| 45 |
> minimal (in the scheme of things) so it shouldn't be a worry. My |
| 46 |
> experience with compiling in tempfs is that it works, but has a much |
| 47 |
> higher failure rate than on disk - i.e., things like OO/Lo, KDE, gcc and |
| 48 |
> glibc have large space requirements that you must make sure tmpfs can |
| 49 |
> satisfy before you start. And if its a busy machine actively using lots |
| 50 |
> of ram it gets "hard". I am making the point that most machines today |
| 51 |
> are way overprovisioned but when you are near the edge, saying things |
| 52 |
> like I gave xGB ram and never needed swap, so you wont either is |
| 53 |
> misrepresenting the situation. |
| 54 |
> |
| 55 |
> BillK |
| 56 |
> |
| 57 |
> |
| 58 |
|
| 59 |
Yes, I did so some testing on whether portage's work directory on tmpfs |
| 60 |
instead of HDD was faster or not and it wasn't much difference. I |
| 61 |
actually had a couple times where it was faster on HDD but could have |
| 62 |
been that some other process took up a few seconds of time too. The |
| 63 |
difference was literally seconds on compiles that were between 30 |
| 64 |
minutes to one hour. |
| 65 |
|
| 66 |
Dale |
| 67 |
|
| 68 |
:-) :-) |
| 69 |
|
| 70 |
-- |
| 71 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |
Archives