Fork me on GitHub
Ben Lieberman15:08:13

Has anyone else experienced some video issues with certain Clojure talks on YouTube? I'm gonna submit a ticket but I get working audio and video that looks like this on @seancorfield’s REPL talk and then Rich Hickey's history of Clojure video. I have no other issues across the site though

Alex Miller (Clojure team)15:08:13

oh, so not ClojureTV. I don't see anything weird like that on the video

Ben Lieberman15:08:31

hm, must be on my end then. Thanks for checking

Bart Kleijngeld10:08:13

For what it's worth: my girlfriend showed me the same issue. She said she read it has to do with having to upgrade Windows. I haven't checked, but thought this might be useful to you. Edit: I pushed her to try and test another browser, and that seems to have helped.


I can't recall the specifics, but I've had similar types of weirdness on YouTube before, always repeatedly on a single channel. I concluded the cause was YouTube generating multiple resolution variants from a single upload, when the source is encoded with a codec version slightly different from the closest matching codec on the server. If you choose a different resolution for paycheck, the problem will likely disappear.


for monitoring a server, do you think the count of open file descriptors is a useful metric? calling lsof | wc -l takes so long. I wonder if cat /proc/sys/fs/file-nr | awk '{print $1}' is interesting. I guess what is really interesting is the proportion of open files to the limit


Adding -nPt to lsof should significantly speed it up.


hm on my local pc it is only 10s down from 13s


Might try also adding b and l in there. For me, just nPt results in 3 s vs 10 s.


I wonder if a lot of docker procs slow it down because I have a lot of docker running rn


prometheus node exporters expose this info


one thing I know now is that with nothing running, it is basically instant 200ms


googleing pormetheus


the prometheus node exporter is based on /proc/sys/fs/file-nr


so was knowing lsof line count or the content of file-nr ever something you wanted to know about your server? Did / does that help? Ok I guess it's a matter of having metrics of the operation of the system.


look into a monitoring system, rather than hand rolling individual metrics


datadog, prometheus, new relic, etc


yes monitoring file descriptors is very useful for server monitoring, fd leaks happen. Most monitoring systems already have the alerts set up for this


it did happen in my previous job (connection reset by client would leave a file open)


ah that is interesting


that sounds like aws servers likely already have something for this?

Aleh Atsman18:08:28

not sure about the exact metric though

Aleh Atsman18:08:47

cloudwatch is used automatically by all servers


Monitoring number of open files is sometimes useful: • you can be running out of file descriptors simply because you open too many files or have too low nofile limit • you might even get a weird OOM error from JVM ("unable to create a new native thread) because of not having enough file descriptors. lsof can be quite slow, especially on macOS. On linux it tends to be much faster but yeah, maybe it still takes time. I wrote a little script which I used for monitoring specific metrics about our java app. That used /proc/sys/fs/file-nr.


I believe datadog & co is interesting and useful, but can be quite expensive for small apps and companies. If you are on AWS you should definitely look at CloudWatch metrics, but I don't think you get this metric automatically:


:thumbsup: 👀