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

Another reason why Docker containers may be slow

hackernoon.com

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Another reason why Docker containers may be slow

#11

Post by willejs »

eikenberry wrote: post #3
lurker9 wrote: post #2

I don't understand why more people don't use Solaris Zones, they seem to me to be the superior solution by far, and with work done by Joyent you now have modern LX-branded zones also. Is the lack of adoption mainly due to the fact that it's Solaris, and not Linux? (Solaris lives on in Illumos et al)

Solaris is not free software and the free software forks never gained much traction. Plus it is now also associated with Oracle which brings along a lot of extra distrust, particularly given how litigious they are.

FreeBSD jails it is then.

Re: Another reason why Docker containers may be slow

#12

Post by travbrack »

eikenberry wrote: post #3
lurker9 wrote: post #2

I don't understand why more people don't use Solaris Zones, they seem to me to be the superior solution by far, and with work done by Joyent you now have modern LX-branded zones also. Is the lack of adoption mainly due to the fact that it's Solaris, and not Linux? (Solaris lives on in Illumos et al)

Solaris is not free software and the free software forks never gained much traction. Plus it is now also associated with Oracle which brings along a lot of extra distrust, particularly given how litigious they are.

Illumos/SmartOS is FOSS

Re: Another reason why Docker containers may be slow

#13

Post by crcl »

rmrfrmrf wrote: post #10

Isn't this kind of thing part of the reason why you log to stdout instead of handling disk writes in your app?

A comment in the Medium article asked the same thing. The author's response:

> I agree that piping all logs to stdout would be the best solution in case of Dockerized microservices. It’s just that in our case we were porting an existing system, which a) already heavily relied on logging to files b) consisted of many microservices itself, which we couldn’t yet split into separate Docker containers but also couldn’t pipe all their logs to the same stdout.

Re: Another reason why Docker containers may be slow

#14

Post by AlphaSite »

jaequery wrote: post #5

on osx, i know for a fact Docker for OSX is pretty darn slow due to its way they handle filesystem. but using Dinghy greatly helped sped everything up due to it using nfs. just in case anyone wanted to know.

You can force docker to mount volumes in a non conistant way. It’s just never clearly documented anywhere.

Re: Another reason why Docker containers may be slow

#16

Post by cpuguy83 »

jaequery wrote: post #5

on osx, i know for a fact Docker for OSX is pretty darn slow due to its way they handle filesystem. but using Dinghy greatly helped sped everything up due to it using nfs. just in case anyone wanted to know.

This will help you get similar fs performance in d4mac without falling back to NFS: https://docs.docker.com/docker-for-mac/osxfs-caching/#tuning...

Re: Another reason why Docker containers may be slow

#17

Post by deathanatos »

dstroot wrote: post #15

Better title: “nother reason why my code is slow and I’m logging too much”

Yeah. The whole article seems to be a bug in the logging library that's in use here, and an area of contention in the kernel? (How many times is his application logging, to cause that much contention?) I'm not sure how Docker figures into it, aside from it easily lets one run multiple instances of an app on the same hardware, but stuff like supervisord will also do that?

I'm not entirely clear as to why a logging library needs to call fadvise; a log file, is, I presume opened in append-only mode. Isn't "append" sufficient advice to the kernel? Also, fadvise needs byte ranges, and I have no idea what you'd pass for a log file…

Re: Another reason why Docker containers may be slow

#19

Post by jaequery »

clintonb wrote: post #9
jaequery wrote: post #5

on osx, i know for a fact Docker for OSX is pretty darn slow due to its way they handle filesystem. but using Dinghy greatly helped sped everything up due to it using nfs. just in case anyone wanted to know.

docker-sync ( http://docker-sync.io/ ) is another option that helps resolve filesystem issues on macOS.

i had high hopes for this when i first heard about it but it's no good for me as it requires you to modify your docker-compose file to suit it's needs

Re: Another reason why Docker containers may be slow

#20

Post by jaequery »

cpuguy83 wrote: post #16
jaequery wrote: post #5

on osx, i know for a fact Docker for OSX is pretty darn slow due to its way they handle filesystem. but using Dinghy greatly helped sped everything up due to it using nfs. just in case anyone wanted to know.

This will help you get similar fs performance in d4mac without falling back to NFS: https://docs.docker.com/docker-for-mac/osxfs-caching/#tuning...

i never tried this but i think it's similar to docker-sync, where you still have to modify your docker compose files. it's not good for people who want a single consistent docker-compose file that would work across varying distributions (ie; opensource project).
Post reply on HN