1 |
"Boyd Stephen Smith Jr." <bss03@××××××××××.net> posted |
2 |
200705050856.32180.bss03@××××××××××.net, excerpted below, on Sat, 05 May |
3 |
2007 08:56:27 -0500: |
4 |
|
5 |
> On Saturday 05 May 2007, Duncan <1i5t5.duncan@×××.net> wrote about |
6 |
> '[gentoo-amd64] Re: [OT] AGPART [SOLVED]': |
7 |
>> Actually, here, I have 8 gigs. That's a bit overkill. I'd probably |
8 |
>> stick with four if I were doing it over, as over four gigs remains |
9 |
>> entirely empty, most of the time, not even used for cache. |
10 |
> |
11 |
> Odd, here I run 4G and it's consistently filled. It's mostly cache and |
12 |
> buffers, but it is most definitely used. I've even got a few 100Mio |
13 |
> swapped out. |
14 |
|
15 |
It's probably just usage patterns. After awhile up, I'll have serious |
16 |
cache, but there's several things that prevents it from getting too big |
17 |
most of the time. |
18 |
|
19 |
1) I swsusp to disk fairly frequently (every day or two, generally). |
20 |
That dumps cache, so I start over when I resume. (OTOH, swsusp also |
21 |
means I too carry some swapped out stuff, generally ~120-200 MB that |
22 |
never swaps back in between suspends.) |
23 |
|
24 |
2) I run MAKEOPTS=-j1000. (Why? Mainly just because I can! =8^) Few |
25 |
merges split even 100 jobs, but some of them do (it's really fun watching |
26 |
the minute load average jump up and up and up to peak at 500 or so, |
27 |
compiling the kernel! =8^), and it's not entirely unusual for C++ jobs to |
28 |
use a gig or more of memory for a single job. Since I also run parallel |
29 |
merges on occasion, it's not unusual at all for me to see 2-3 gigs of |
30 |
temporary (maybe two minutes, peaking for just a few seconds) application |
31 |
memory in use by portage jobs, in addition to the half gig to gig of |
32 |
regular app memory in use, and the possibly several gigs of tmpfs |
33 |
PORTAGE_TMPDIR in use as scratch space by parallel merges. Of course, |
34 |
that squeezes out regular cache, and I often see memory use including |
35 |
cache drop by four gigs, sometimes more, from peak merge usage to post |
36 |
merge. |
37 |
|
38 |
3) I don't run the indexer for slocate. In fact, I don't even have it |
39 |
merged. On a lot of systems, that's the big daily cache gobbler right |
40 |
there. If it's indexing 50 gigs of disk files, pretty moderate by |
41 |
today's standards, it'd fill 50 gigs of cache memory, if it had it to |
42 |
fill. Obviously, anyone who runs that is going to have a full cache |
43 |
until they do something that grabs the memory and then releases it, no |
44 |
matter /what/ their memory size (within reason). |
45 |
|
46 |
4) My actual daily working fileset isn't that great. When I play music, |
47 |
it's often off the net, not off my disk, so I'm not using disk for that. |
48 |
I don't have the big movie cache many have. I don't play gigabytes worth |
49 |
of games. Etc. I have gigs of files, but don't tend to use them daily, |
50 |
and with swsusp every day or two, and running many of the kernel rcs and |
51 |
sometimes even the daily git snapshots (not to mention when I have a |
52 |
kernel bug open and I'm rebooting new kernel builds multiple times a |
53 |
day), many times I just don't actually /read/ (or write, since those |
54 |
would be cached after write as well) multiple gigs of files between cache- |
55 |
dumps. |
56 |
|
57 |
So as I said, practically speaking, four gigs of memory would be plenty, |
58 |
as I'd be a bit more conservative on my merges then, and would figure 2-3 |
59 |
gigs of cache and 1-2 gigs of app memory most of the time. |
60 |
|
61 |
(Right now, after returning from swsusp a few hours ago, and spending |
62 |
most of my time since in the text groups/lists, I'm running about 200 MB |
63 |
still swapped out from the suspend, and total memory use, app, buffer, |
64 |
and cache, of only ~1/2 GB. That's as displayed on ksysguard, with KDE |
65 |
including kmail and amarok in the system tray, and pan open to read and |
66 |
reply to the lists (gmane list2news gateway) with, all started before my |
67 |
last swsusp, so only the apps and state I've actually used since then |
68 |
have been swapped back in. If I closed and reopened pan, so it had to |
69 |
reread its lists, and ran an emerge --pretend world, to recache that |
70 |
info, I'd be back up at a gig to a gig and a half total usage, cache |
71 |
included, probably.) |
72 |
|
73 |
-- |
74 |
Duncan - List replies preferred. No HTML msgs. |
75 |
"Every nonfree program has a lord, a master -- |
76 |
and if you use the program, he is your master." Richard Stallman |
77 |
|
78 |
-- |
79 |
gentoo-amd64@g.o mailing list |