| DFP | "I would strongly recommend having at least a small swap partition in there too." What would be the benefit of having a swap partition? | 12:31 |
|---|---|---|
| DFP | The way I see it, it only makes OOM killer kick-in much later when something hogs memory. Which is undesirable. | 12:31 |
| DFP | Maybe for very RAM-limited scenarios it provides ability to store inactive program state, but I wouldn't think that would come into play at 4-8 GiB of RAM and up. | 12:34 |
| fsmithred | cryptsetup refuses to close an encrypted partition because it's "still in use". How do I find out what's using it? lsof |grep dev/mapper tells me nothing. | 13:55 |
| fsmithred | Oh, if I grep 'mapper' it shows me a udisksd process. I guess I'll try killing that. | 13:57 |
| fsmithred | Nope. it's still in use. | 13:59 |
| fsmithred | bye | 13:59 |
| devfan_ | is there a method of running the ncurses installer from the desktop.iso or was it removed for the new gui method? | 14:33 |
| rwp | DFP, Swap is beneficial because the kernel always has some memory pages that are used to boot and never used again but can't be released. | 18:54 |
| rwp | Under memory stress those can be paged out to swap increasing the amount of RAM available during that time of memory stress. | 18:54 |
| rwp | Also that person said they were planning to use ZFS. ZFS itself uses memory during it's own file system operation, and it has a reputation for being a little heavy, though I have not seen it be unduly heavy myself. I use ZFS and it is great. But best not to short it on memory. | 18:54 |
| rwp | When ZFS needs just a little more RAM then other pages can be swapped out to provide it and cushion ZFS so that it can complete. You don't want the OOM Killer getting involved at that time. | 18:54 |
| rwp | Most disks and SSDs these days are measured in the terabytes and allocating a gigabyte to swap is insignificant to the storage but perhaps critical when memory is short. | 18:54 |
| rwp | Everyone always thinks that their system will thrash simply because it has a little swap and that's just silly because it won't. And trust me if your system is thrashing it will slow down to where you will know and be able to look. | 18:54 |
| rwp | Also the OOM Killer is stupid af regardless of how people have tried to add tweaks and tunes to it and it often kills critical things. On an enterprise server if that happens I claim the best and safest recovery is to reboot the server, always, because it is easier than trying to deal with recovering the system from generally unpredicted OOM Killed processes. | 18:55 |
| rwp | And then there are laptops. I like my laptop to be able to hibernate to disk. That needs enough swap to hold hibernate the RAM. I am pretty sure that system being discussed was a desktop not a laptop but just pointing out that laptops need swap to hibernate RAM into at hibernation time. | 18:58 |
| DFP | rwp: Thanks for the response. Personally I don't need hibernation, and I have had situations where a program misbehaves, takes all available memory, system starts paging to disk, and I have to wait minutes to have a task manager open to try to close it. Though in that case the program might've been hogging CPU as well. | 19:19 |
| DFP | I also usually run my system within 1-2 GiB leeway of the RAM limit, so in that case I don't really see a need for swap. How much memory would be saved by swapping out those kernel pages? Can it be more than ~20 MiB? | 19:21 |
| rwp | I have seen as much as 400-500 megabytes of memory from unreleasable memory that the system can page out and use if needed. | 19:22 |
| rwp | I am going to say that I think it would be astounding if someone can actually "run my system within 1-2 GiB leeway of the RAM limit" as how to do that escapes my understanding. Which will sound like I am criticizing but really I just need to say it in order to discuss the point. | 19:24 |
| rwp | I think what is actually being seen is file system buffer cache using ram that would otherwise not be working for you. | 19:24 |
| rwp | The kernel puts that RAM to work being a file system buffer cache and it is elastic in size and it will expand to use as much RAM for that purpose as possible. | 19:25 |
| rwp | Because free memory is memory that is not working for you. So let's get it working doing something useful. And buffer cache is EXTREMELY useful. It accounts for most of the performance feel of the system. | 19:25 |
| rwp | That's a good use for the RAM and if the system needs it for userland or for other things then it flushes those file system buffer cache pages and uses them first. Reducing the overall size of the buffer cache pool. | 19:28 |
| rwp | If a system needs to use a lot of ram then the userland amount of ram will be increased at the expense of file system buffer cache pages. Perhaps squeezing the file system buffer cache down to virtually zero size. At that time the system will feel like it is crawling because without buffer cache available I/O will be a disk drive speeds. Better if on SSD but quite poor if on spinning disks. | 19:29 |
| rwp | I have had people IRL convinced that the system was swap thrashing at that time, even though their system had no swap configured. Because it ran slow and felt like it. But it was not swap thrashing. It just lacked enough RAM to perform at what we now consider a normal speed using a good amount of file system buffer cache. And every command they invoked would have to read fresh from disk at the slow spinning disk speeds. | 19:31 |
| rwp | I like using "htop" for seeing this. The memory bar graph shows the memory. Green is userland memory to the left. Blue and Yellow is buffer cache to the right. | 19:33 |
| rwp | On a modest ram system of say 16GB, If the divide is around half way with half the ram in userland (firefox!) and half in buffer cache then that's probably okay. But if all of the bar is green userland and very little is buffer cache then it needs either more ram or less userland running (exit firefox). | 19:33 |
| rwp | And of course we always have systems on both sides. A 256MB Raspberry Pi on the small side which never has enough buffer cache and a 512GB RAM monster server on the large side which doesn't have enough file system to ever fill up the RAM. | 19:35 |
| DFP | 'escapes my understanding.' Currently running a browser with a music video playing, Discord, Hexchat, EMACS and some other software -- I have 2.5 GiB taken, with filesystem cache taking about 4 GiB. I still have ~1.5 GiB totally free. | 22:26 |
| DFP | So userland memory combined with filesystem cache still leaves ~1.5 GiB free. | 22:26 |
| nemo | rwp: Firefox tends to use a certain % of the available ram. I've run it comfortably on systems with very little ram | 22:39 |
| nemo | you can't really compare its usage on a system w/ 16 gigs and one with 1 or 2. | 22:39 |
| nemo | w/ the default settings ofc, you can tune it more aggressively manually | 22:40 |
| nemo | main impact on systems with less ram is fewer simultaneous processes (maybe even just one) and background tabs being unloaded pretty much immediately | 22:40 |
| rwp | DFP, Good deal! That's the system working very well for you. | 22:43 |
| rwp | nemo, I was mostly making fun of firefix because it is such an easy target since it is almost always the biggest memory pig on anyone's system. But truth be told I don't really have problems with it either. My main laptop for years has had only 8GB of ram and it's been a very good machine even with Firefox always running. | 22:44 |
| rwp | What is bad about both Firefox and Chromium is that both of them seem to be always active, always poking at the network, always running the cpu, and never truly idle. | 22:46 |
| nemo | rwp: yeah, but it's mostly 'cause they are doing a balance between performance and memory usage | 23:08 |
| nemo | rwp: since the memshrink project they've been pretty good on constrained systems | 23:08 |
| nemo | considerably better than chrome IMO | 23:08 |
| rwp | It's good to hear that people have been working on making them play nicer in a smaller ram system. That's probably why I haven't had much problem with it lately. Good! | 23:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!