7 ms·
Mach's designers simply assumed that systems would be rebooted often enough
- jarin 16y agoI wonder if that's been fixed in the OS X/Darwin version of Mach, seems like the only time I ever reboot my MacBook is for system updates.
- zackb 16y agoI wonder if there's an update for my MkLinux box! http://mklinux.org/ http://mklinux.org/
- mikeryan 16y agoThis: the only time I ever reboot my MacBook is for system updates Seems to indicate that it has ;-)
- eibrahim 16y agoreally man? maybe you are not using your macbook long enough or you are simply browsing the internet with it? I reboot my macbook pro (running leopard) as often as I reboot my windows 7 PC which is not much. Except I use the Win7 machine 90% of the time and for much more "intensive" stuff.
- blago 16y agoAs a fellow mac user: If you are rebooting your Mac for reasons other then system upgrade, something is wrong with your machine. I say this as someone who compiles from source and runs server software on my mac almost every day. mogodb, apache, nodejs, mysql, tomcat is just the tip of the iceberg in the server department.
- technomancy 16y ago> If you are rebooting your Mac for reasons other then system upgrade, something is wrong with your machine Indeed; that is the point of the article. =)
- larsberg 16y agoOr you have made the grave, grave mistake of installing Adobe products on your machine.
- Derbasti 16y agoExcept for those who rely on Boot Camp for gaming. These people have to reboot whenever they want to switch from work mode to game mode.
- JoeAltmaier 16y agoMaybe app users experience this. I use a Mac Mini for development/test as an alternate platform. I have to reboot the dang thing every day or two. The development tools hang and screw up. The network drops and needs to be unplugged/plugged back in or rebooted. The debugger totally fails to breakpoint and only a reboot will fix it. I alternate between banging my head on the wall, and white-hot fury at the thing. Fortunately I only occasionally have to verify the code still runs there, and don't have to live in that environment.
- jarin 16y agoI use it probably 14+ hours a day, and it's variously running MySQL, Redis, MongoDB, Photoshop, 600 million Chrome tabs, Xcode and Starcraft 2 whenever possible :) I did experience memory leaks with pretty much every Bittorrent client, but I haven't torrented any uh, Linux distros in forever.
- reneherse 16y agoJust asking, but how do you keep so many Chrome tabs open without things getting sluggish? My MBP (2008 pre-unibody/Leopard) seems to get bogged down with just a couple score of Chrome tabs. Granted, I don't know much about what's going on under the hood (I'm a designer, not a programmer) but Activity Monitor shows that each tab uses a gig of virtual memory...
- foljs 16y ago> Just asking, but how do you keep so many Chrome tabs open without things getting sluggish? My MBP (2008 pre-unibody/Leopard) seems to get bogged down with just a couple score of Chrome tabs. Avoid Flash. Install something like ClickToFlash, FlashBlock etc. I have tens of tabs open no problem. (Then again, I'm on a Quat iMac)
- tjarratt 16y agoJust a guess, I think there might be some APIs available in SnowLeopard that allow Chrome to write its tabbed content to files and read it in asynchronously more easily than they could have in Leopard. Sometimes when I switch to a tab that has been idle for over a hour, I notice it takes chrome some time to render it again. Also, most developers tend to buy machines with the maximum RAM they can. I've got 4GB in my macbook pro and the 20 chrome tabs can't be taking up more than 500MB all together. Comparatively, Safari seems to take up a lot more memory than Chrome.
- seabee 16y ago> Sometimes when I switch to a tab that has been idle for over a hour, I notice it takes chrome some time to render it again. That sounds like paging in effect, which is decades old. Maybe you just notice it more now!
- CountSessine 16y agoThe original poster in that thread was running 10.5.8. No one in the thread posted saying that they couldn't repro the port leak. The thread is quite recent, the latest post being from earlier today. I think we have to assume that the port leak is still there in the most recent version (10.6.6). I do hope that the poster had misunderstood Avie Tevanian in his conversations with him. Tevanian was one of Apple's chief architects and was one of the big wheels responsible for NextStep's transformation to OS X. It would be kind of outrageous for an OS architect to believe that it's at all acceptable to allow user-mode processes to cause kernel resource leaks.
- jrockway 16y agoIt was an engineering trade-off like any other. Would you be willing to reboot your computer once a month if it meant everything would be 1000x faster? Of course. So were the Mach designers, apparently.
- jwatzman 16y agoWhile the discussion in that thread may or may not apply to OS X, be very careful when saying "X is true about Mach therefore X is probably true about Darwin". A friend of mine put it very well: OS X was Mach once in the same way that orcs were elves once.
- eschaton 16y agoYou're misinterpreting the post; Mikel wasn't talking about the same leak the original thread was. He was just talking about how he fixed a leak many years ago. Using Mach ports correctly without leaking is hard, similarly to how using C's malloc/free without leaking is hard. The former no more implies a current flaw in Mach than the latter implies a current flaw in C stdlib.
- klodolph 16y agoKernels should not have resource leaks. A web server that leaks memory implies nothing wrong with the clients, a kernel that leaks memory implies nothing wrong with the user space programs. It just means that there are cases that the kernel developers didn't think of, just like the people who made Apache didn't think of the Slowloris attack. Heck, a few months ago someone exhausted Linux kernel fds in just by shuffling socket pairs around (just 40 lines of C with three syscalls). These are problems, ranging from remote DOS attacks, local DOS attacks, to accidental DOS attacks.
- mobilemonkey 16y agoI'm not going to pretend I know what Mach is, but around here, (big company that you're familiar with), rebooting/bouncing the servers is pretty much how issues are dealt with. "Response times outside of SLA: bounced the server." "Database connections timing out: bounced the server." "Users experiencing high load times for pages: restarted JVMs. Then bounced the servers." Root cause seems to be "server up too long."
- derleth 16y agoMach is a microkernel. That means it's a way to design an OS such that most of the things application programs rely on are outside the kernel, provided by servers that can be restarted and replaced without rebooting the whole system. For example, the majority of the filesystem is provided by a filesystem server, most of the networking code is in a networking server, and so on. You begin to see why a microkernel that needs to be bounced more often than, say, Linux, which is not a microkernel, begins to lose some of the appeal of having a microkernel in the first place. (Aside: Mac OS X is based on Mach, but practically all of the stuff applications see is provided by a single server which (to the best of my knowledge) can't be restarted without taking down the whole system. It's a hybrid design.) Also, just to confirm a stereotype, do you use Windows for your servers?
- stcredzero 16y agoAlso, just to confirm a stereotype, do you use Windows for your servers? Related tangent: There was a time when the the US military's COTS (Civilian Off The Shelf) initiative resulted in AEGIS missile cruisers running largely on machines running Windows NT. Yes, the ships responsible for screening carrier task forces against attack -- had to be rebooted on a weekly schedule. To be fair, the unmolested NT kernel is rock solid. I know people used to run RAID arrays with it, but for the desktop, Microsoft allowed the crossing of certain architectural lines.
- rst 16y agoAnd if the NT machines running your missile cruiser don't come back up, then you have real problems. During trials, the USS Yorktown had to be repeatedly towed into port after systems failures... http://lists.essential.org/1998/am-info/msg03829.html http://lists.essential.org/1998/am-info/msg03829.html
- pinko 16y agoRelevant: http://www.usenix.org/event/osdi04/tech/full_papers/candea/candea.pdf http://www.usenix.org/event/osdi04/tech/full_papers/candea/c... Microreboot – A Technique for Cheap Recovery "A significant fraction of software failures in large-scale Internet systems are cured by rebooting, even when the exact failure causes are unknown. However, rebooting can be expensive, causing nontrivial service disruption or downtime even when clusters and failover are employed. In this work we use separation of process recovery from data recovery to enable microrebooting – a fine-grain technique for surgically recovering faulty application components, without disturbing the rest of the application."
- bm98 16y agoMy favorite Linux bug (since fixed): https://bugzilla.redhat.com/show_bug.cgi?id=97373 https://bugzilla.redhat.com/show_bug.cgi?id=97373 (System UPTIME reported incorrectly): "Steps to Reproduce: 1. Boot Linux system; 2. Go away for 497 days; 3. check uptime"
- stcredzero 16y agoTake it off the queue and go on a 16 month sabbatical to somewhere really beautiful. Come back, check uptime, report to your boss that you've recreated it and you'll start digging in the code. http://xkcd.com/583/ http://xkcd.com/583/
- aidenn0 16y ago"Hello IT, have you tried turning it off and on again?"
- foljs 16y agoThat was about a version of Mach nearly 20 years ago... That "costly housekeeping" that they avoided then (for performance reasons) should have not been a problem for over a decade now --and the intentional leaking must have been fixed a long time ago too. Trouble is, without investigation into the CURRENT status, that anecdote is worthless...
- fleitz 16y agoThere are some great reasons due to memory fragmentation and other issues to reboot your systems every two or three days anyway. Plus, if you pride yourself on having failover, DR systems, etc, rebooting lets you know that your failover systems are working.