Some Mac users top the idiot level on security and here is why. Recently I started playing with OSX on my Mac. As a systems administrator, I naturally sought to find security solutions for this machine because it’s public facing, I do the same thing on Windows and Linux. You should always have Antivirus of some kind. Lets just say, Virus is interchangeable (for this instance) with Trojan, Rootkit and you’re an idiot. You must have missed the memo on OSX/HellRTS.D, maybe? Just too busy thinking your machine can’t be infected to notice?
Image courtesy of two idiots & Apple forums
Here are the problems with Mac users: 1.) They listen to Apple and misinterpret “Mac OS X doesn’t get PC viruses” from http://www.apple.com/macosx/security/ (these are the same people who deny the iPhone antenna problems ~ and instead of fixing it, point out other phones have the same mistake ~ as if that’s going to make you look like less of an asshole) the statement means Mac can’t be infected by Windows ONLY viruses, it doesn’t mean there are no fucking viruses for your Mac, asshats. 2.) They listen to the idiots in the figure above, who say it’s theoretically impossible (by implication of course.) but security labs beg to differ and 3.) they don’t actively push for antivirus because they think they don’t need it, leaving people who actually know a bit about security up to themselves having to do twice the work when they have suspicious feelings.
Some notes for you Mac fanboys: ClamAVX is for Windows Viruses mostly, it has no true virus definitions for Linux. Sophos is an industry known and trusted security solution that can find Malware for OSX, as a matter of fact, they discovered more OSX based Malware than Apple did themselves and patched for it long before Apple did in their internal malware detection. Norton is the only solution sold by Apple, this means that Apple believes Norton is a decent solution, I thought you fanboys followed Apple around, if Apple sells Norton, do you not trust it?
The news has come in that BP has finally capped the flow on the Gulf crude oil leak. After months of it leaking and ruining the Gulf Coast we can finally see some real progress and hopefully they can fully stop it and not continue to let it go on even 1oz. Keep trying and make sure your bullshit CEO doesn’t go on Golfing trips when he should be capping oil leaks in the US.
Earlier today I was officially introduced to the Droid X. A bigger screen version of my phone touting Android 2.1, a better physical keyboard design and a processor that isn’t much faster than what I OC’d my phone to. At first, I was rather happy to say hi to the phone because it is, after all, the younger brother of my phone (in an Everybody Hates Chris fashion of course) and was meant to be the new bad ass-ness to the Android market, the phone that was to give the big “fuck you” to iPhone fan-boys every where and because I skipped over the Incredible due to some privacy issues (even though they fixed them, I am not a very forgiving person when it comes to security leaks, at all) I was hoping this would be the next bad boy to try and pick up that is until I found the boot was encrypted, which means we can’t beef up our phones for real. I mean really Motorola, what the fuck was going through your mind besides (we are going to fail) when you pulled that bullshit move? There are phones with the same processor with way more to offer. Namely a few upcoming Samsung phones. I would have said alright if you would have put a screen as nice as the iPhones, but you didn’t. Average hardware, above average hardware protection, in my opinion that’s above average fail.
The fist modern hard drive or what we could consider modern (by comparison) would date back to 1956, at IBM of all places. It was called the IBM 305 RAMAC and it consisted of 50 24-inch platters that spun at 1200RPM and stored 5MB of total data with an access time of just under 1 second (by normal standards of today, this would be like running Windows Vista on a Windows 98 machine).
If your hard drive was that big, can you imagine how big your entire computer would have been? Yeah, not bad considering in 50 years we now have computers the size of 1/8th of the original platter in the first HD. Maybe even less, if we want to consider our 1.2GHZ+ smart phones as computers, I mean by definition they are, but by application are they?
Gamers who like to game with privacy and anonymity rejoice, our privacy has been kept. On the 9th Blizzard CEO and Co-Founder Mike Morhaine explained that he would not enforcing the new Real ID system for forum users. While a lot of people initially hated it, some stated it would stop the trolls and general negativity against so called “dumb people” however it would not have curved that one bit.
NGINX (pronounced Engine-X) is one of the most lightweight and efficient HTTPD servers you could ever come across, but it’s no stranger to lack of performance tuning from the average user. Today we will be going through some basic tips and tricks to keep NGINX performing in tip top shape and learning a bit about how to adjust spawns based on situation.
1.) Spawns. Most people think that having more spawns is better, but this couldn’t be more wrong. In a normal situation, less spawns with higher request rates might be better. For example, on some of our high traffic sites, we have 20 spawns with as much as 15K requests per spawn, recycling spawns to fast on a high traffic site can lead to ultimate disaster as they have to garbage collect faster. A good example is the style we use on EnvyGeeks:
The general theory behind what you would normally do depends on the situation. If Johns server sits dead most of the day and get nominal traffic during normal traffic times for his site, it would be better to increase processes and reduce connections because they will recycle and clean up better and you won’t run into possible serial issues on the dead times, however, if John has consistently high traffic we should increase worker connections and reduce worker processes so we aren’t trying to garbage college to fast or too soon. Nobody likes a defunct process now do they?
2.) CPU. Setting the CPU affinity (sticking processes to a specific processor or core for the purpose of caching and efficiency) can be beneficial for efficiency but sometimes trivial (not worth it.) First, lets start with the load-balancing theory. People often assume that CPU affinity will solve the load-balancing issues they have, this ultimately is not true, for the most part because the algorithm would allow for a processes with affinity for another processor to move to yet another processor if it’s deemed more efficient. An example is if process A and process B are set to CPU 1, and CPU 1 is at 100% but CPU 2 is at 10% process B could be moved to CPU 2 for now to give better efficiency. It doesn’t solve it because process C and process D were set to CPU 2 and now they are now using that processor with process B, this by system theory is more efficient but by balancing and efficiency theory is not because we might have needed to dedicate that processor to those processes which were at the time, sleeping, and we lost our affinity because we moved to a new processor.
Lets move on with explaining a multi-socket system and the efficiency. When a processes loads it can go to pretty much any processor, and move between them (by system algorithm for process efficiency.) On a multi-socket system, we share no caching at all. In other words we have no affinity with any processor at all because we switch back and forth between processors and cores, this can be very inefficient so we would set the CPU affinity because that process could ultimately have remnants remain cached in the processor, and for something like a high-traffic site, it most likely would have remnants remain cached in the processor. If the process is consistently switching between sockets, we lose that cache, we lose that efficiency and we have no affinity to any processor.
Now lets dig into most dedicated server users, and even most VPS users. When we think in terms of multi-socket, we know we have more than one physical CPU and by default no affinity at all, but on a VPS, and even on most dedicated servers, we always have partial affinity depending on how many cores our VPS has, this is because Cores share some caches, it’s efficient to set the affinity on a single-socket multi-core server because of the clear fact that we only have partial affinity and by theory we could have more affinity. It can be trivial to set it on a VPS because well, most VPS users who aren’t typically aimed specifically for the cloud get no traffic at all, so the affinity can be well, worthless because by the time that process is used again, the cache could be gone. So you have to be the one to decide whether it’s efficient or trivial for you to use CPU affinity. Lets take a look at 4 core CPU affinity for NGINX:
If we take a look at the above example, we see that we have 6 affinities, for 6 processes, we schedule these across 3 cores on a 4 core system. This is typically how we would do affinity. You normally take (Cores-1) and double, triple, quadruple and so forth to equal processes and set the affinity in a round situation, in this example, every 4th process should hit CPU/Core 2. We always leave CPU 1 open for Network operations, and other tasks for the system itself and then let the operating system decide if it’s more efficient to send a process with an affinity to core 1 if it’s core is busy. On a system with hyper-threading it’s beneficial to keep your affinity off of the second thread because it has full affinity and is sharing resources with it’s sister thread. Some people will argue that you should include sister threads, but I argue irrelevancy because we are ultimately just ending up sharing resources between two processes, example: If process a and b are on thread 1 and 2 on core 1 then they might as well both be on core 1 instead of core 1 thread 1 and core 1 thread 2 because those 2 threads constantly fight for 100% on that core. So you need to schedule around cores, not threads and cores, this keeps efficiency.
3.) If to be or not if to be. Whatever the hell that’s supposed to mean. The truth is, we can’t avoid an if situation on NGINX, but we can avoid inefficient if methods, some of the most basic and inefficient if methods are using -e instead of two -f. Lets take a look at an efficient rewrite using an if statement in NGINX:
If we are serving high traffic we need to use specific checks to keep the system efficient, if we use -e we constantly stat the top-level directory for that file recursively, this is horrible and bad. Lets avoid this situation, here is an example of an unoptimized if statement for NGINX:
if (!-e $request_filename) { rewrite . /index.php last; }
4.) Use ePoll, KQueue (FreeBSD), or /dev/poll (Solaris) instead of legacy poll. Event Models are very important to system efficiency, you don’t want to end up with Select or legacy poll now do you? I normally set this manually to be specific so I don’t end up with select or legacy poll, even though the Kernel supports all 3 and by theory ePoll is the most suitable, I want to specifically use ePoll. You can set the event model in the events directive:
events { use epoll; }
5.) Match worker_rlimit_nofile to the number of possible connections. If John has 10 spawns with 5 thousand connections he should match his worker_rlimit_nofile to 10*5000 or (10*5000)*2 as this will allow him to control the number of file descriptors and keep better control of his server.
6.) Turn multi accept off. On a normal server multi accept can remain on, because most servers aren’t so high traffic, but on a server that runs nominal resources, but wants to push decent traffic, it’s beneficial to turn multi accept off so we aren’t running up our process connections with just a few users. Here is a better explanation. If John has multi accept on, Jason can tap his server for as many connections as possible I myself can tap my own site for 200+ connections with multi accept on, this is bad so we turn multi accept off so we can more efficiently manage our connections and not accept so many connections from one user. You can set this in events:
events { multi_accept off; }
After doing that, your server should be able to more efficiently manage it’s traffic because it’s not running up so many connections on a single user. We should always try to keep strict tabs on our connections because by theory, we do have a limit after all, unless we go farming or up our resources significantly.
So ladies and gentlemen, we come to our conclusion, these 6 tips can help you run your server more efficiently, I hope they help you as much as they’ve helped me and my clients keep our servers in tip top shape!
