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