<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style> ***: carvite has quit IRC (*.net *.split) <br> sjackso has quit IRC (*.net *.split) <br> jpalmer has quit IRC (*.net *.split) <br> KDE_Perry has quit IRC (*.net *.split) <br> KILLALLHUMANS01 has quit IRC (*.net *.split) <br> DaCa has quit IRC (*.net *.split) <br> milki has quit IRC (*.net *.split) <br> toddf has quit IRC (*.net *.split) <br> up_the_irons has quit IRC (*.net *.split) <br> d^_^b has quit IRC (*.net *.split) <br> mike-burns has quit IRC (*.net *.split) <br> mhoran has quit IRC (*.net *.split) <br> carvite has joined #arpnetworks <br> sjackso has joined #arpnetworks <br> jpalmer has joined #arpnetworks <br> KDE_Perry has joined #arpnetworks <br> KILLALLHUMANS01 has joined #arpnetworks <br> DaCa has joined #arpnetworks <br> milki has joined #arpnetworks <br> toddf has joined #arpnetworks <br> up_the_irons has joined #arpnetworks <br> d^_^b has joined #arpnetworks <br> mike-burns has joined #arpnetworks <br> mhoran has joined #arpnetworks <br> asimov.freenode.net sets mode: +oo toddf up_the_irons <br> nesta has quit IRC (Ping timeout: 245 seconds) <br> nesta has joined #arpnetworks <br> Lucifer333 has quit IRC (Quit: Leaving) <br> Lucifer333 has joined #arpnetworks brycec: I couldn't say. I have neither the expertise nor the data to fully form a hypothesis. ***: BryceBot has quit IRC (Ping timeout: 258 seconds) KILLALLHUMANS01: Well cool/fuck. <br> Reproduced my issue even though I slowed down the whole process. ***: brycec has quit IRC (Ping timeout: 248 seconds) KILLALLHUMANS01: So I'm hitting this when I copy from one database to another (moving BryceBot and other services off MySQL, finally.) I wrote a Ruby script based on Sequel's (bin/sequel) copy-database mode. It does a big SELECT on the source database (some half-million rows as I recall) and then for each result, INSERTs into the new database. <br> I thought the act of slamming so many rows into the database at such a high rate was responsible for bringing my system down, so I put a sleep in - 1 row every 5 seconds. BAM still died. <br> What's kindof funny is that neither MySQL nor Postgres (nor my script) are showing in htop (well MySQL is, just not at high load) <br> Also weird is that kswapd is responsible for a relatively large chunk of CPU, along with kworker/0:3 (I'll need to check which device this refers to), but there is ZERO swap usage as of yet, and still a decent chunk of free memory for that matter. <br> https://www.dropbox.com/s/0o1e1e39we6drcp/screenshot_2016-12-29_09-12-03.png?dl=0 <br> I'm guessing that something (MySQL?) tried to allocate a big piece of memory, forcing the system to start trying to figure out what all it can swap out, but it's having trouble... Either deciding, or actually writing to swap. <br> Regrettably I don't have an iotop this time. <br> Also of note, pretty low load average... Then again, htop hasn't refreshed any time recently. It probably froze when the kernel started looking for volunteers to swap out. <br> So... Yeah. There's a bit more data, I guess. At least as much as I can get. Seems like I can reproduce it relatively easily, at least with this current state of things. <br> (Or maybe it's the Ruby process trying to allocate?) <br> Unrelated question - On consule.cust, the "broadcast message" function ^Ecb, does that go to all users on consule.cust, or just those connected to my VPS? (If the former, then I apologize for my language just now.) ***: BryceBot has joined #arpnetworks <br> brycec has joined #arpnetworks nathani: maybe you need moar RAM brycec mercutio: or maybe it's some kernel bug <br> hmm i'm not sure if it broadcasts to all <br> we should try it :) brycec: <u>nathani</u>: You don't even work for ARP, why are you trying to sell me on more RAM? :P (Once I'm off MySQL, I'll actually have an even smaller memory footprint :) ) nathani: :-) mercutio: linux's memory management used to be really really bad <br> and having more ram could make it worse sometimes <br> linux aggressively forces memory into being used as disk cache <br> so you can get memory pressure even when you have plenty of spare memory if you read a lot of data in <br> in 2.2.x kernels it was all over the place <br> erk, i just remembered that was like 15 years back <br> haha brycec: Yeah I'm pretty sure it was better by 3.16.0-4-amd64 mercutio: i don't notice much changes in new kernels these days <br> i do wonder when BBR will be merged though <br> oh it's in 4.9 brycec: Anyhow, now paginating my input so hopefully no random memory pressure. So far, so good... <br> 3+ million rows, 1000 at a time. <br> With periodic breaks every 5 seconds to allow disk writes to flush if they want, etc -: brycec is watching the source MySQL database gradually use more RAM while Postgres just sits back and takes it. mike-burns: My current client uses MySQL; it's been fun watching each new dev they hire raise the same question within their first week: "So, when are we switching to Postgres?" brycec: lol up_the_irons: <u>nathani</u>: i'm using weechat and screen. non-ascii is no problem.:) <br> <u>JC_Denton</u>: i use mutt ***: nesta has quit IRC (Quit: WeeChat 1.6) <br> nesta has joined #arpnetworks JC_Denton: <u>up_the_irons</u>: 1.7.x? up_the_irons: no 1.5.x <br> it's old JC_Denton: *shrug* <br> 1.7 isn't that new ;) <br> but it did mainline the sidebar patch, which is why i built from source on my debian login host <br> was having a god awful annoying screen corruption bug <br> i finally figured it out, though. i needed to compile against wide-ncurses vs. plain mercutio: i thought it was slang, hmm <br> mine is curses too up_the_irons: i c ***: ziyourenxiang has joined #arpnetworks mercutio: i'm using 1.4? <br> it seems i am way behind JC_Denton: you can compile it with slang