Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How setting the TZ environment variable avoids thousands of system calls

blog.packagecloud.io

Post reply on HN
Print view View original

141–148 of 148 posts

Re: How setting the TZ environment variable avoids thousands of system calls

#141

Post by jwhitlark »

segmondy wrote: post #67
AceJohnny2 wrote: post #46

> In other words: your system supports calling the time system call via the Linux kernel’s vDSO to avoid the cost of switching to the kernel. But, as soon as your program calls time, it calls localtime immediately after, which invokes a system call anyway. This reminds me of an article by Ted Unangst[1], in which he flattens the various libraries and abstractions to show how xterm (to cite one of many culprits) in on…

With the layering of clusters, containers, micro services, bet you probably have 10x worse than that. There is always a cost to abstraction. On the surface it might make things simpler but if you were to peel it apart, you would reveal a hidden layer of complexity. Hopefully, it's done well right enough that there will never be a need to peel it apart.

This is why I always liked the idea of Unikernels, they let us reset our abstractions without giving up all we've learned in the last couple decades.

Re: How setting the TZ environment variable avoids thousands of system calls

#142

Post by deathanatos »

vsl wrote: post #136
deathanatos wrote: post #128

Earlier quoted context omitted.

> To do it simply yes, but not correctly. No, it do it correctly doesn't require filesystem access either. I've read both articles in the past: neither refutes the point I made above. If I were incorrect, linking to an article that enumerates tens of things (some of them arguably incorrect) isn't useful. If you're trying to imply that you need to take timezones into account, yes, you do. Yes, typically those definiti…

Read the damn article. It explains how it's localtime (the function you need to format time in user's time zone) that makes the stat call - to check if the ocnfigured time zone changed.

> Read the damn article.

> Please don't insinuate that someone hasn't read an article

I read the article. Yes, localtime requires the call; that wasn't my point. My point was that for plenty of common, server-side code, either this isn't required, or is inconsequential.

The former case that I was consider is the formatting of timestamps into TZs in the context of a request being server by a server. Most server-side TZ conversions I've ever needed can't call localtime, b/c localtime is wired to not the user's timezone, but the TZ of the machine the server's code is running on, which is typically either nonsense, UTC, or whatever the devs like. Server side code needs (of course, YMMV) to use the user's TZ, whatever that may be, so I'm making calls to a library built for that, e.g., pytz, which doesn't need to stat() that the machines TZ as there is no point to doing so.

The other instances the author lists that do require localtime are instances where localtime's stat call is the least of your worries, as you're about to perform other operations that are much more expensive.

Re: How setting the TZ environment variable avoids thousands of system calls

#143

Post by cbsmith »

deathanatos wrote: post #114
cbsmith wrote: post #56

Earlier quoted context omitted.

> System calls in Linux are really fast. So saving "thousands" of system calls when /etc/localtime is in cache doesn't actually save that much actual CPU time. "fast" is a relative term, and is somewhat orthogonal to "efficient". There's a reason why certain functions use a vDSO. If you're just going to use a syscall anyway, there's kind of no point.

You're assuming that all cases where the vDSO call is made gets paired with a real syscall; that's simply not the case. There are plenty of calls in a server that won't need localtime (basically, anything that just needs the current time in UTC: best-practice code should not be looking at the machine's TZ setting¹). Look at the examples the article's author offers: > formatting dates and times This shouldn't require…

> You're assuming that all cases where the vDSO call is made gets paired with a real syscall; that's simply not the case.

I don't believe I was. I was merely assuming that there a lot of cases (as in, potentially thousands of times a second) where code needs the system time they also want the localtime.

> There are plenty of calls in a server that won't need localtime (basically, anything that just needs the current time in UTC: best-practice code should not be looking at the machine's TZ setting¹)

As the article demonstrates, whatever we might believe about best practice, actual practice seems to include a lot of cases where it is called.

Given that a given epoch time value can map to different dates & times, depending on timezone... I'm not sure why you think formatting dates & times wouldn't require considering the desired timezone.

You're similarly mistaken that logging a message involves hitting disk. It's a very common configuration for high throughput logs to buffer writing to disk across multiple messages and/or forward to a remote server.

Similarly SQL queries don't necessarily involve hitting the network (some don't even involve crossing an IPC boundary). Even if you do hit the network, once again, it is very common for multiple network requests to be buffered in user space before making a syscall, and of course a single SQL statement could involve more than one localized timestamp value (though I'd like to think in that case the the local timezone would be cached).

> ¹one of my old teams had an informal rule that any invocation of datetime.datetime.now() was a bug.

Well, if you are writing in Python, then worrying about the syscall overhead of reading the local timezone would seem odd (and for that matter, Python does some odd things with timezones, so I'm not even sure this would reliably trigger the syscall).

Re: How setting the TZ environment variable avoids thousands of system calls

#144

Post by cbsmith »

deathanatos wrote: post #142
vsl wrote: post #136

Earlier quoted context omitted.

Read the damn article. It explains how it's localtime (the function you need to format time in user's time zone) that makes the stat call - to check if the ocnfigured time zone changed.

> Read the damn article. > Please don't insinuate that someone hasn't read an article I read the article. Yes, localtime requires the call; that wasn't my point. My point was that for plenty of common, server-side code, either this isn't required, or is inconsequential. The former case that I was consider is the formatting of timestamps into TZs in the context of a request being server by a server. Most server-side T…

Timezones don't exclusively belong to users... Most syslogs (up until systemd) are configured to write out logs in machine localized time. Same goes for web servers. Really, there are a ton of cases where servers need to consider their timezone. I don't much like it, but it nevertheless is true.

Re: How setting the TZ environment variable avoids thousands of system calls

#145

Post by cbsmith »

curlypaul924 wrote: post #123
geofft wrote: post #64

Earlier quoted context omitted.

It's hard to do that without any system calls, though. The way you'd do this is to open an inotify (or platform equivalent) file descriptor on the first call to localtime(), and on future calls, only bother statting /etc/localtime again if that file descriptor reports something has changed. But checking if an FD has data requires a system call; you'd do a non-blocking read on the FD (or a non-blocking select or poll,…

What about calling mmap to map /etc/localtime into memory? The file would still have to be parsed for every call to localtime(), but the system call is avoided. (Better yet, if it were possible to memory-map the directory entry for /etc/localtime, parsing could be avoided as well). I agree the best solution is to provide a more sensible API. Why should an application be limited to only _one_ timezone?

mmapping doesn't solve the problem unless the file was edited in place (rather than overwritten as is commonly done). You'll just have an mmap on an inode that is no longer visible in the directory.

Re: How setting the TZ environment variable avoids thousands of system calls

#146

Post by cbsmith »

noselasd wrote: post #111
cbsmith wrote: post #96

Earlier quoted context omitted.

At least on key platforms, it's pretty easy to use an event driven model and watch for updates. Hell, if the vDSO handled TZ it'd be no problem.

I'm not saying it's impossible, but if you actually sit down and attempt to add this to glibc, you will come to the realization that it is not easy at all. If you want to e.g. use the inotify mechanism you have a few key decision points to make * There's no place where glibc can run an event loop to watch for the changes, the application might not have an event loop. * If you need to integrate with an event loop the…

I don't think it is quite so bad. The fork/event loop/thread problems already get dealt with for a variety of other cases. It's handy when you can coordinate with the runtime itself and exploit the level of indirection that the rest of the runtime has.

Re: How setting the TZ environment variable avoids thousands of system calls

#147

Post by JdeBP »

cbsmith wrote: post #144
deathanatos wrote: post #142

Earlier quoted context omitted.

> Read the damn article. > Please don't insinuate that someone hasn't read an article I read the article. Yes, localtime requires the call; that wasn't my point. My point was that for plenty of common, server-side code, either this isn't required, or is inconsequential. The former case that I was consider is the formatting of timestamps into TZs in the context of a request being server by a server. Most server-side T…

Timezones don't exclusively belong to users... Most syslogs (up until systemd) are configured to write out logs in machine localized time. Same goes for web servers. Really, there are a ton of cases where servers need to consider their timezone. I don't much like it, but it nevertheless is true.

> Most syslogs ... servers need

You have been using poor logging softwares. For the past decade and a half (or more) some of us have been using logging softwares that write out logs without converting timestamps to a local format or a local time, relying rather upon log post-processing tools to convert them to different (sometimes multiple) timezones of our choosing and at whim when we want to read our logs. Our servers haven't needed to consider timezones for all of those years, and our log-writing softwares don't call a localtime() function of any stripe. Please do not tar us with your brush.

* http://unix.stackexchange.com/a/326166/5132

* http://jdebp.eu./Softwares/nosh/guide/log-post-processing.ht...

* http://jdebp.eu./Softwares/nosh/guide/timestamps.html

* https://sawmill.net/formats/qmail_tai64_n.html

* https://www.elastic.co/guide/en/logstash/2.4/plugins-filters...

* http://docs.projectcalico.org/v1.6/usage/troubleshooting/log...

Re: How setting the TZ environment variable avoids thousands of system calls

#148

Post by cbsmith »

JdeBP wrote: post #147
cbsmith wrote: post #144

Earlier quoted context omitted.

Timezones don't exclusively belong to users... Most syslogs (up until systemd) are configured to write out logs in machine localized time. Same goes for web servers. Really, there are a ton of cases where servers need to consider their timezone. I don't much like it, but it nevertheless is true.

> Most syslogs ... servers need You have been using poor logging softwares. For the past decade and a half (or more) some of us have been using logging softwares that write out logs without converting timestamps to a local format or a local time, relying rather upon log post-processing tools to convert them to different (sometimes multiple) timezones of our choosing and at whim when we want to read our logs. Our serv…

I haven't been using them I hate the whole approach and defer any rendering of timestamps in logs. I'm just pointing out that it is very commonplace. Set up any distro's server distribution with the default settings and then track how often the localtime file gets touched...
Post reply on HN