553
Linux processes (lemmy.world)
top 50 comments
sorted by: hot top controversial new old
[-] Blackout@kbin.run 107 points 10 months ago

It was little Bobby Tables

load more comments (1 replies)
[-] count_dongulus@lemmy.world 73 points 10 months ago

Alright who's running the database on the same machine as the server...👀

[-] tias@discuss.tchncs.de 68 points 10 months ago

If you can do this, do it. It's a huge boost to performance thanks to infinitely lower latency.

[-] jmcs@discuss.tchncs.de 11 points 10 months ago

And infinitely lower reliability because you can't have failovers (well you can, but people that run everything in the same host, won't). It's fine for something non critical, but I wouldn't do it with anything that pays the bills.

[-] tias@discuss.tchncs.de 24 points 10 months ago* (last edited 10 months ago)

I work for a company that has operated like this for 20 years. The system goes down sometimes, but we can fix it in less than an hour. At worst the users get a longer coffee break.

A single click in the software can often generate 500 SQL queries, so if you go from 0.05 ms to 1 ms latency you add half a second to clicks in the UI and that would piss our users off.

Definitely not saying this is the best way to operate at all times. But SQL has a huge problem with false dependencies between queries and API:s that make it very difficult to pipeline queries, so my experience has been that I/O-bound applications easily become extremely sensitive to latency.

[-] Katana314@lemmy.world 6 points 10 months ago

I’m going to guess quite a people here work on businesses where “sometimes breaks, but fixed in less than an hour” isn’t good enough for reliability.

load more comments (2 replies)
load more comments (2 replies)
load more comments (1 replies)
[-] crony@lemmy.cronyakatsuki.xyz 48 points 10 months ago

Most beginner selfhosters.

[-] adarza@lemmy.ca 34 points 10 months ago

and most every cpanel (and every other web host panel) box on the planet.

web, ftp, database, mail, dns, and more. all on one machine.

load more comments (1 replies)
load more comments (2 replies)
[-] cm0002@lemmy.world 70 points 10 months ago

Ok, now I need a 8 season animated show and at least 2 direct-to-TV movies of this

[-] bobs_monkey@lemm.ee 25 points 10 months ago

Best I can do is a Netflix series that gets cancelled halfway through season 2 and a fan-made animation spoof on YouTube

load more comments (3 replies)
[-] msage@programming.dev 60 points 10 months ago

Fuck MySQL, all my homies hate MySQL.

Postgres is the way to go.

[-] kitnaht@lemmy.world 26 points 10 months ago
[-] msage@programming.dev 14 points 10 months ago

Yes, Maria too.

Postgre is the way

load more comments (1 replies)
[-] Anticorp@lemmy.world 22 points 10 months ago

It was you! You killed it.

[-] msage@programming.dev 8 points 10 months ago

I do admit to moving the company cluster from MySQL to Postgres.

But only most of the traffic, some traces still remain, so the original MySQL still works

[-] esc27@lemmy.world 60 points 10 months ago

Random guess, a php error caused Apache to log a ridiculous number of errors to /var/log and on this system that isn’t its own partition so /var filled up crashing MySQL. The user wiped /var/log to free up space.

[-] harmsy@lemmy.world 6 points 9 months ago

That's not far off of something that happened to me once a few years ago. My computer suddenly started struggling one day, and I quickly figured out that my hard drive suddenly had 500 gigs or so of extra data somewhere. I had to find a tool that would let me see how much space a given folder was taking up, and eventually I found an absolutely HUMONGOUS error log file. After I cleared it out, the file rapidly filled up again when I used a program I'd been using all the time. I think it was Minecraft or something. Anyway, my duck tape solution was to just make that log file read-only, since the error in question didn't actually affect anything else.

[-] Honytawk@lemmy.zip 54 points 10 months ago

Plot twist: it was the user

[-] ICastFist@programming.dev 7 points 9 months ago

That's not even a plot twist, that's expected user behavior

[-] Buffalox@lemmy.world 50 points 10 months ago

All evidence point to suicide.

[-] Unbecredible@lemm.ee 28 points 10 months ago

I hadn't realized this was a .ru domain....

[-] MajorHavoc@programming.dev 21 points 10 months ago

Maybe it's a 'Windows' server...

[-] Blue_Morpho@lemmy.world 32 points 10 months ago

Systemd. SQL is now in Systemd.

[-] Samsy@lemmy.ml 9 points 10 months ago

Dont spoil. That's the secret in Episode 5.

[-] Lost_My_Mind@lemmy.world 26 points 10 months ago

I understand none of this.....

[-] Samsy@lemmy.ml 16 points 10 months ago

"Among us" but for Linux nerds.

[-] tias@discuss.tchncs.de 24 points 10 months ago

It was Java, coaxing the Linux OOM killer into doing the job

[-] tal@lemmy.today 22 points 10 months ago

It looks like the OOM killer has struck again.

[-] Rexelpitlum@discuss.tchncs.de 22 points 10 months ago

/var/log has been deleted, you say...

I think we all know what this means, don't we?

[-] Rexelpitlum@discuss.tchncs.de 14 points 10 months ago

Hint

ls -ld /var/log
drwxrwxr-x 18 root syslog 4096 Aug 11 08:13 /var/log

[-] verstra@programming.dev 8 points 10 months ago

I have no clue. Root nuked the logs? Why? OOM killer does not do that.

[-] Rexelpitlum@discuss.tchncs.de 13 points 10 months ago

Well, there is only one who could have erased all traces of the SIGKILL...

And only the SIGKILLER would have had reason to do so...

load more comments (2 replies)
[-] hemko@lemmy.dbzer0.com 7 points 10 months ago

That seems so obvious I think we're missing something

[-] Rexelpitlum@discuss.tchncs.de 9 points 10 months ago

Whatever, we have a suspect.

Bring in GDB to do the interrogation! And perhaps also call Nice, he can play the good cop...

[-] hemko@lemmy.dbzer0.com 6 points 10 months ago

Forgive me my ignorance, but since Apache is running as root, couldn't PHP inherit it's permissions?

[-] lawrence@lemmy.world 5 points 10 months ago

The Apache main process runs as root. When it receives a request, it spawns a child process that doesn't run as root. PHP runs as the same user as the Apache child process.

[-] jollyrogue@lemmy.ml 4 points 10 months ago

Or PHP runs in its own fastcgi like process under a different account.

[-] jordanlund@lemmy.world 22 points 10 months ago

This process has been murdered mysteriously.

[-] WhiskyTangoFoxtrot@lemmy.world 20 points 9 months ago
[-] uranibaba@lemmy.world 17 points 10 months ago

Will there be a follow up?

[-] Tamkish@programming.dev 14 points 10 months ago

I did it like this: 🔫 BANG WhooOooOoopty doOoO

[-] jlh@lemmy.jlh.name 12 points 10 months ago

It was the kubelet after MySQL failed his liveness probes

[-] bionicjoey@lemmy.ca 6 points 10 months ago
[-] ggppjj@lemmy.world 6 points 10 months ago

It was taking away resources from the coffee cam. Had to go.

[-] hakunawazo@lemmy.world 6 points 9 months ago

Like everytime with natives, it was a race condition cascade of table locks followed by mysql suicide caused by bad cronjob scripts implemented by the user.

load more comments (1 replies)
[-] TeoTwawki@lemmy.world 5 points 9 months ago

Mariadb did it with the candlestick in the library.

load more comments
view more: next ›
this post was submitted on 12 Aug 2024
553 points (96.8% liked)

Comic Strips

17174 readers
630 users here now

Comic Strips is a community for those who love comic stories.

The rules are simple:

Web of links

founded 2 years ago
MODERATORS