=== Dee is now known as darknite | ||
kantlivelong | does RPCNFSDCOUNT not work in 16.04 for nfs-kernel server? it looks to me that its never used by the service unit file but the unit does use RPCNFSDARGS | 04:40 |
---|---|---|
kantlivelong | i only ask because increasing the thread count seems to make no diff | 04:42 |
=== lotuspsychje_ is now known as lotus|celery | ||
=== elsheepo is now known as beatzz | ||
lordievader | Good morning | 06:44 |
=== cpaelzer__ is now known as cpaelzer | ||
lucidguy | Ok, Server with 192GB of ram. I assume that's GIGA, and not GIBI. Convert that to Gibibytes and you get 178GiB. If you do a free -g on the box you get 187? I'm pretty sure df is in GiB, so why is there about 10GiB discrepancy? | 14:52 |
sdeziel | lucidguy: AFAIK, RAM is expressed with a 1024 base value for "K" | 14:54 |
lordcirth | sdeziel, -g is gibibytes according to the manpage | 14:55 |
sdeziel | lordcirth: I'm referring to the 192GB part | 14:55 |
lordcirth | Ah, the manufacturer? Yeah I don't know what they use | 14:56 |
lucidguy | Ohh, so ram is sold in GiB not GiG like drives? | 14:56 |
sdeziel | lucidguy: that said, that doesn't explain where the 5GB went | 14:56 |
blackflow | 192GB of physical RAM but not every bit is addressable. dmesg will show available physical addressable RAM in bytes. | 14:56 |
sdeziel | lucidguy: I'd check 'dmesg | grep -i memory' and see how the kernel reserved that RAM | 14:57 |
sdeziel | lucidguy: on a random box here, I have: Memory: 4740848K/4914680K available (8613K kernel code, 1335K rwdata, 4028K rodata, 1484K init, 1284K bss, 173832K reserved, 0K cma-reserved) | 14:59 |
lucidguy | Memory: 196455640K/199738988K available (12300K kernel code, 2473K rwdata, 4288K rodata, 2408K init, 2416K bss, 3283348K reserved, 0K cma-reserved) | 14:59 |
sdeziel | lucidguy: and this VM has 4800MiB assigned | 14:59 |
sdeziel | If I'm doing my maths right, your kernel only sees 190.4 GiB | 15:00 |
lucidguy | sdeziel: Does that make sense? | 15:00 |
sdeziel | and 3.13 GiB are 'reserved', whatever that means | 15:00 |
blackflow | stack <-> heap gaps'n'all, that RAM is not addressable. | 15:01 |
sdeziel | lucidguy: I don't know why the kernel doesn't see the full 192 GiB, looks like the EFI/BIOS is hiding some of it or something like that but I'm just guessing at this point | 15:01 |
lucidguy | Ok, this makes more sense now. I knew storage, like drives were in GiG and not GiB, thought RAM was sold/represented the same way. | 15:02 |
sdeziel | blackflow: I would assume that only apply to virtual addresses, not physical ones, no? | 15:02 |
patdk-lap | if you have some pci devices that use memory (aka video cards) | 15:02 |
patdk-lap | that memory is not usable by the os | 15:02 |
sdeziel | yeah ^ | 15:02 |
sdeziel | but 2G of video RAM on a server sounds a little excessive ;) | 15:03 |
lucidguy | My last statement is accurate right? Disks are still sold in GiG? | 15:03 |
patdk-lap | I think some network cards do this also, and infiniband cards, but those are rare | 15:03 |
patdk-lap | ya, I guess it has to be a real server motherboard to have 192gb ram anyways | 15:03 |
patdk-lap | could need it if it was a windows server :) | 15:04 |
lucidguy | Ubuntu Server | 15:04 |
patdk-lap | efi/bios doesn't hide it | 15:04 |
patdk-lap | hmm, that motherboard was designed for only ubuntu server? | 15:04 |
lucidguy | I wonder if the BOSS storage controller is taking some | 15:05 |
sdeziel | patdk-lap: do you know where the NIC/video cards reserved chunks would be visible/accounted for? Would the kernel still see that memory or not? If it does, would they be in the 'reserved' section from that dmesg line? | 15:06 |
patdk-lap | the kernel won't see it, it will be subtracted before the os boots | 15:06 |
lucidguy | Thanks guys, appreciate the responses, solved my mystery. | 15:07 |
sdeziel | OK so that would explain where the 1.6GiB went | 15:07 |
lucidguy | I'm sure I read online that ram sold was represented in GiG not GiB.. grr | 15:07 |
sdeziel | one day, I hope to understand what the kernel reserves... | 15:07 |
patdk-lap | well, I cannot remember how it does it now | 15:08 |
patdk-lap | but should reserve <1meg | 15:08 |
patdk-lap | still lots of dma stuff that only works below 1meg or 16megs | 15:08 |
sdeziel | 170MiB on that i440fx VM | 15:08 |
sdeziel | out of 4800MiB assigned to it | 15:08 |
blackflow | sdeziel: yes, but that will always reduce the availability of physical RAM as long as physical addresspace is less than virtual (which is always unless you had gazillions of ram) | 15:09 |
blackflow | oh yeah, there's the GPU as well, sometimes it shares the system RAM | 15:10 |
patdk-lap | said that way above | 15:10 |
blackflow | sorry, didn't see it | 15:10 |
sdeziel | blackflow: I don't understand how the gap between stack and heap wouldn't be usable by the kernel. That gap is in virtual address space alone, no? | 15:11 |
patdk-lap | it is | 15:19 |
patdk-lap | but that doesn't really help the kernel | 15:19 |
patdk-lap | if the kernel was places randomly in each process, none of it's memory pointers or anything would work | 15:19 |
sdeziel | patdk-lap: I'm arguing with: blackflow: stack <-> heap gaps'n'all, that RAM is not addressable. | 15:20 |
patdk-lap | define addressable :) | 15:20 |
sdeziel | more specifically the 'not addressable' part | 15:20 |
patdk-lap | if you use it, it will cause a exception | 15:20 |
sdeziel | not addressable by the userspace process | 15:21 |
patdk-lap | it is addressable | 15:21 |
patdk-lap | it's not backed by anything, and needs to be allocated | 15:21 |
sdeziel | what I'm saying is this gap is purely virtual, it doesn't waste any physical RAM | 15:21 |
patdk-lap | well, there is some waste, but your talking on a small level, 4k | 15:22 |
sdeziel | I don't understand why the gap would be allocated at all | 15:22 |
patdk-lap | or maybe more for empty stack allocations | 15:22 |
patdk-lap | unused stack space | 15:22 |
patdk-lap | unused heap space | 15:23 |
patdk-lap | and mmap | 15:23 |
sdeziel | right but that's not part of the gap | 15:23 |
patdk-lap | outside of that, nothing is allocated to physical or swapped ram | 15:23 |
sdeziel | or is it? Is there actually a gap or can the stack and heap grow till they meet? Causing explosion | 15:23 |
patdk-lap | heh? | 15:24 |
* sdeziel vaguely remembers stackclash | 15:24 | |
patdk-lap | of course they can grow till they meet | 15:24 |
blackflow | sdeziel: ah yes, these days it's all in virtual address space only | 15:24 |
patdk-lap | when all the virtual address space is used up | 15:24 |
patdk-lap | the kernel will allocate physical and swap memory to back those pages | 15:24 |
patdk-lap | if there isn't enough swap space, then it will blow up sooner | 15:25 |
blackflow | sdeziel: they could meet in the past, there was a CVE about it, forgot the details. but iirc kernel now protects against that. | 15:25 |
sdeziel | https://access.redhat.com/security/vulnerabilities/stackguard | 15:26 |
blackflow | ah yes, the stack clash, you said it. | 15:26 |
jamespage | coreycb: apologies - dpdk things blew out my morning today - I'll endeavour todo some of the dep updates for train m1 tomorrow | 16:27 |
coreycb | jamespage: no problem at all, i'm going to focus on it this afternoon and see what deps i can get through. | 16:48 |
=== kallesbar_ is now known as kallesbar | ||
=== MassDebates_ is now known as MassDebates | ||
ahasenack | rafaeldtinoco: ok, so, sponsoring | 19:08 |
rafaeldtinoco | ahasenack: tks, NOW ill finally cherry-pick iproute2 patches for cosmic and disco then. | 19:09 |
rafaeldtinoco | ahasenack: do I have to ping someone for the missing +1s on the review ? | 19:10 |
rafaeldtinoco | (server team / etc) | 19:10 |
rafaeldtinoco | or just let it hang in there | 19:10 |
ahasenack | rafaeldtinoco: no, one is enough from our team | 19:10 |
ahasenack | and I can sponsor | 19:10 |
ahasenack | ahasenack: we usually just do a final check, like the bank asks you to ack sometihng on the phone loud and clear | 19:11 |
ahasenack | rafaeldtinoco: rather | 19:11 |
ahasenack | rafaeldtinoco: so, ok for having 96b1b4a6b461effe47a19d5d62d9f0e9825e9fcb sponsored? | 19:11 |
rafaeldtinoco | ahasenack: +1 | 19:11 |
ahasenack | ok | 19:12 |
ahasenack | rafaeldtinoco: two things I'll do then | 19:12 |
ahasenack | rafaeldtinoco: one is push the upload tag, which marks the commit has corresponding to the dput I'll do right after | 19:12 |
ahasenack | rafaeldtinoco: and second is the actual dput | 19:12 |
ahasenack | rafaeldtinoco: that will upload the package to eoan-proposed, where it will go through what we call migration checks | 19:13 |
ahasenack | rafaeldtinoco: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 19:13 |
ahasenack | rafaeldtinoco: it may take a while to show up there after the upload, but I'd ask you to do what we call "follow its migration" | 19:13 |
ahasenack | i.e., keep an eye there to see if it passes the tests and actually lands in the archive | 19:13 |
rafaeldtinoco | will do | 19:13 |
ahasenack | rafaeldtinoco: that page refreshes about twice an hour, it's a bit irregular | 19:17 |
rafaeldtinoco | good to know | 19:19 |
ahasenack | rafaeldtinoco: it's currently building: https://launchpad.net/ubuntu/+source/iproute2/4.18.0-1ubuntu3 | 19:23 |
ahasenack | a good hint that it migrated, and usually comes way before the excuses page updates, is the email from lp saying the bug was closed, since it's mentioned in d/changelog | 19:23 |
rafaeldtinoco | ok | 19:24 |
ahasenack | rafaeldtinoco: you can now also move the card to "external dependency", signaling we now have to wait for this external process | 19:30 |
rafaeldtinoco | ahasenack: done | 19:30 |
ahasenack | and I just assigned it to you, that was missing | 19:30 |
rafaeldtinoco | hum. maybe others are missing that too, /me review | 19:30 |
rafaeldtinoco | ahasenack: disco and cosmic are good also | 19:39 |
rafaeldtinoco | ahasenack: are we waiting for full verification on eoan ? | 19:40 |
ahasenack | ok, let's wait for eoan to migrate | 19:40 |
ahasenack | yep | 19:40 |
rafaeldtinoco | ok | 19:40 |
cncr04s | my grub won't boot from my mdadm array anymore | 19:50 |
cncr04s | some recent update broke it | 19:51 |
cncr04s | its an imsm array | 19:51 |
rafaeldtinoco | ahasenack: alright. so after dput to -proposed, and update_excuses are good, how does it get to -updates ? | 20:01 |
rafaeldtinoco | (in ccase this was an actual sru) | 20:02 |
ahasenack | rafaeldtinoco: for eoan there is no -updates yet, so it will just move to where it should be | 20:02 |
rafaeldtinoco | yep | 20:02 |
ahasenack | main or universe | 20:02 |
rafaeldtinoco | ah gotcha | 20:02 |
ahasenack | for srus, | 20:02 |
ahasenack | the upload to proposed will be in an unapproved state | 20:02 |
ahasenack | until a member of the sru team gets to it | 20:02 |
rafaeldtinoco | ah i know where that is | 20:02 |
rafaeldtinoco | all makes sense now | 20:03 |
ahasenack | if it's accepted, then this person will move it to -proposed, lp will get that standard comment about it having been accepted and asking for help testing it, etc | 20:03 |
ahasenack | we also have to check the excuses page for that particular ubuntu release, to see if dep8 tests failed | 20:03 |
ahasenack | if there are failures, they need to be investigated, and either justified in the bug with a comment, or fixed in a subsequent upload | 20:04 |
rafaeldtinoco | ok | 20:04 |
ahasenack | rafaeldtinoco: the per-release excuses page is like this: https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html | 20:05 |
ahasenack | replace "bionic" with your release of choice | 20:05 |
rafaeldtinoco | ok, saving bookmarks | 20:05 |
ahasenack | yep | 20:05 |
=== techmagus_ is now known as techmagus | ||
Soni | what are alternatives to lighttpd that will fit a shitbox VPS? 1 core, 256 MB of RAM, 10 GB of disk, etc | 20:39 |
Soni | I don't like the configs, I have the same block copypasted 5 times, once for each subdomain, and I wanna add a blog to it. | 20:40 |
OerHeks | a blog on a vps, interesting | 20:45 |
ploxiln | Soni: I use nginx a lot, it's also very efficient ... it's pretty popular so you may have already considered it | 20:48 |
ploxiln | there's an "nginx-light" package with a reduced set of features enabled | 20:49 |
Soni | but how hard is it to configure? | 20:49 |
ploxiln | I suppose it takes some getting used to, but it can be very concise to just serve some files or just proxy. fcgi requires a separate helper like spawn-fcgi | 20:49 |
ploxiln | https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/ | 20:51 |
sdeziel | Soni: I'd advise sticking to nginx-core which is an Ubuntu specific flavor that mirrors upstream default plugin selection, that's the one in 'main' | 20:52 |
sdeziel | Soni: with that version, you get a handful of plugins that you can disable to reduce the RAM usage. Those plugins are for TCP and mail proxying | 20:52 |
sdeziel | Soni: with those plugins removed, my TLS/HTTP 2.0 nginx on 18.04 takes only 5.5M of RAM ;) | 20:57 |
Soni | maybe I should just use thttpd | 21:06 |
=== Greyztar- is now known as Greyztar | ||
Soni | hm | 21:13 |
Soni | it's really hard to fit a blog engine into a shitbox VPS apparently | 21:14 |
sdeziel | Soni: if 5.5M of RAM is too much for you, then yeah, you'd need to use something != nginx | 21:15 |
Soni | does nginx have some plugin to turn an atom feed into an HTML blog? | 21:15 |
sdeziel | Soni: the biggest RAM consumers are often the DB engine and PHP depending on your blog | 21:15 |
Soni | so I edit the .atom and it changes the blog automatically? | 21:15 |
sdeziel | Soni: not sure that is what you are looking for but I found this : https://ef.gy/serving-an-atom-bundle | 21:17 |
Soni | okay, let's see if I can make any sense of this stuff | 21:21 |
Soni | first, how do I clean the package cache? | 21:21 |
Soni | actually hm is it safe to just remove everything in /var/cache? | 21:22 |
sdeziel | apt-get clean | 21:33 |
sdeziel | Soni: this should reclaim some space | 21:33 |
Soni | sdeziel: that's only for apt tho, I have stuff like the webserver as well | 21:34 |
sdeziel | Soni: I don't know your server but I'd recommend to tread carefully, rm -rf can hose a server pretty quickly ;) | 21:35 |
Soni | sdeziel: so can certbot. doesn't stop me from using it. | 21:35 |
sdeziel | Soni: I find dehydrated less intrusive but I guess it's a question of personal taste | 21:36 |
Soni | hm I wish I knew about that before setting up certbot | 21:38 |
Soni | would probably be lighter on disk usage as well | 21:39 |
sdeziel | dehydrated only deps are bash and curl IIRC | 21:41 |
Soni | anyway, any tool to clean up /var/cache? | 21:42 |
OerHeks | !info Polipo | 21:49 |
ubottu | polipo (source: polipo): lightweight, caching web proxy. In component universe, is optional. Version 1.1.1-8 (bionic), package size 174 kB, installed size 702 kB | 21:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!