Slashdot Mirror
Kernel Comparison: Web Serving On 2.4 And 2.6
An anonymous reader writes "Many improvements have been made in the Linux 2.6 kernel to favor enterprise applications. This article presents results from the IBM Linux Technology Center's Web serving testing efforts, comparing the Linux 2.4 and 2.6 kernels from various aspects. The highlights here are the key enhancements in the 2.6 kernel, the test methodologies, and the results of the tests themselves. Bottom line: the 2.6 kernel is much faster than 2.4 for serving Web pages, with no loss in reliability."
I see a great push everywhere for everyone to start using 2.6. Why, if youre successfully using 2.4 or 2.2 in your current installation. I remember 2.4 took a LITTLE while to iron out.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
See, all that Unix code that IBM stole from SCO and inserted into the Linux kernel was worth it!
How much of this performance boost is thanks to SCO code? This is not a troll, but a serious question.
Aside from a small performance boost, is there really any reason to update perfectly stable systems? My shop has been using a few boxen running RedHat 5.2 for almost seven years now. If everything is stable, why upgrade?
One future, two choices. Oppose them or let them destroy us.
I don't know about you guys, but I'm not too sure that I would describe this article as an examination of an "Enterprise application" on Linux.
Enterprise applications are many things to many people, but rarely are they web servers.
Enterprise servers are generally run complex applications running many complex operations.
While I'm sure IBM's web server is very good, I don't think that it would be typical of an "Enterprise application".
My point is, while I'm sure this is a fantastic article examining performance improvements between Linux kernel versions, let's not pretend it's something that it isn't.
"O(1) scales well..."
No, really?
While the performance gains are impressive (about 5 times as many pages under 2.6) it also shows that 2.6 used 5.6 times more RAM to serve the increased number of pages. If RAM on the system isn't limited, the performance gain is insane. If the system is already overloaded w/respect to RAM, it likely won't help much and there's a *slight* chance it would actually perform worse.
;o)
Of course, this is just a benchmark
SUMMARY
/dev/sda1 * 1 500 4016218 83 Linux native (SCSI hard drive 1, partition 1) /dev/sda2 501 522 176715
This article explains how to remove the Linux operating system from your computer and install Windows XP. This article assumes that Linux is already installed on your computer's hard disk, that Linux native and Linux swap partitions are in use (which are incompatible with Windows XP), and that there is no free space left on the hard disk.
NOTE: Windows XP and Linux can coexist on the same computer. For additional information, refer to your Linux documentation.
MORE INFORMATION
To install Windows XP on a computer on which Linux is currently installed (and assuming that you want to remove Linux), you must manually delete the partitions used by the Linux operating system. The Windows-compatible partition can be created automatically during the installation of Windows XP.
IMPORTANT: Before you follow the steps in this article, verify that you have a bootable disk or bootable CD-ROM for the Linux operating system, because these steps completely remove the Linux operating system from your computer. If you intend to restore the Linux operating system at a later date, verify that you also have a functional backup of all the information stored on your computer. Additionally, you must have a full release version of Windows XP to use during this installation. If you intend to use a Windows XP upgrade CD-ROM, a CD-ROM of a qualifying Windows product must be available. Setup from the Windows XP upgrade CD-ROM will prompt you for this CD-ROM.
Linux file systems use a superblock at the beginning of a disk partition to identify the basic size, shape, and condition of the file system.
The Linux operating system is generally installed on partition type 83 (Linux native) or 82 (Linux swap). The Linux boot manager (LILO) can be configured to start from either of the following locations:
* The hard disk Master Boot Record (MBR)
-or-
* The root folder of the Linux partition
The Fdisk tool included with Linux can be used to delete the partitions. (There are other utilities that work just as well, such as Fdisk from MS-DOS 5.0 and later, or you can delete the partitions during the installation process.)
To remove Linux from your computer and install Windows XP, follow these steps:
1. Remove the native, swap, and boot partitions used by Linux:
1. Start your computer with the Linux Setup floppy disk, type fdisk at the command prompt, and then press ENTER.
NOTE: For help with using the Fdisk tool, type m at the command prompt, and then press ENTER.
2. Type p at the command prompt, and then press ENTER to display partition information. The first item listed is hard disk 1, partition 1 information, and the second item listed is hard disk 1, partition 2 information.
3. Type d at the command prompt, and then press ENTER. You are then prompted for the partition number that you want to delete. Type 1, and then press ENTER to delete partition number 1. Repeat this step until all the partitions have been deleted.
4. Type w, and then press ENTER to write this information to the partition table. Some error messages may be generated (because information is written to the partition table), but they should not be significant at this point because the next step is to restart the computer and then install the new operating system.
5. Type q at the command prompt, and then press ENTER to quit the Fdisk tool.
6. Insert either a bootable floppy disk or the bootable Windows XP CD-ROM, and then press CTRL+ALT+DELETE to restart your computer.
2. Follow the instructions on the screen to install Windows XP.
The installation process assists you in creating the appropriate partitions on your computer.
Sample Linux Partition Tables
Single SCSI Drive
Device Boot Start End Blocks Id System
The new linux kernel is great, but the reason the this particlular kernel results is better performance ("5 times better") is because the application framework it is testing is horrible.
All of the "enterprise" applications in this test have several performance cripling features in common: socket per thread connections, fundemental reliance on threads, and massive memory foot print. Apache has one thread/process (the diff is a stack) per connections. Java requires a sizable multiple of memory usage as most other application languages (C/C++ obviously, but also Perl, Python, and PHP). J2EE is an inherently thread driven programming framwork.
So yes, Linux 2.6 ameliorates the downsides of unnecessary use of threading. It makes thread creation and context switching even faster on the Linux platform.
And Yes, Linux 2.6 memory management is fundementally better. Reverse Page Table Entry mappings make finding victim pages better; and it is designed to avoid victimizing active pages better.
But could you all imagine if people were designing fundementally better application framworks? Event driven application architectures like TwistedPython and POE, or Event-thread hybrid systems like SEDA.
The performance stats given in that article are shit, complete utter shit. I know. In the proprietary world I work in, I code faster programs on the same Linux platform on a daily basis; orders of magnitude faster.
All the accomplishments of Linux 2.6 can be used for true performance programming. I plead with you all, stop using Threads until you know what they are good for. Stop using the stack to maintain your program state. Throw off the shackles and learn to program network servers.
-- I am not a fanatic, I am a true believer.
i was just wondering if there would be
...
:P
any improvement to scheduling on
two processor system if it
wasn't SMP (symmetric multi processor)
but asymmetric.
one processor doing the scheduling (over kill?)
for the second processor
if you had 8 processor two processors would do
the scheduling. this is interessting 'cause
as far as i can tell the scheduling idea
of linux is kindda using two "processes"
to implement the schedular. with eight
processors and two processors doing the
scheduling maybe get a dimension higher (4)?
i never had a multiprocessor system or even
hyperthreading, but it sounds interessting
considering the possibilty running a "real"
OS on one processor and having it run
a virtual box (or a second layer on the second
processor "slut processor")
2 cents
Don't think so anyway. According to the author
Ingo Molnar:
On Thu, 18 Dec 2003, Ingo Molnar wrote:
> Jeff Garzik wrote:
>
>>Are you sure? I could have sworn Ingo made the scheduler magically
>>HT-friendly...
>
> nope, it's not in 2.6 yet. This area is still under development,
> with various approaches being considered.
>
> Ingo
I would be interested in knowing which MPM module(s) they used with Apache in their testing. Whether they used worker, prefork, or something else could make a big difference in serving performance. It would also test different areas of kernel performance I would think.
TwistedPython runs everything from a single thread. Even if you have multiple threads, only one thread can be running at a time due to Python's GIL (Global Interpreter Lock).
Diregard the fact that TwistedPython is still in its infancy and thus immature compared to its rivals.
The fundamental problem with it is that it will not scale well to multiple processors because all of the python threads must interact and share the same memory. It's not like Apache which has one master process that handles incoming connections, and several children distributed across the processors, using seperate sections of memory - it is only a single process with multiple Python threads, forced to run one after another thanks to the GIL.
Apache scales far better than TwistedPython. When you have a properly scaleable database backend, or some kind of application logic layer that can scale, then it behaves very well as the load increases and on more advanced hardware.
Understand that I'm not saying that "TwistedPython Sux!" I am saying that I won't be using it for an application server that must scale. Once Python overcomes the GIL problem (and offers shared memory for Python objects) then TwistedPython may begin to have some hope of actually scaling.
The radical sect of Islam would either see you dead or "reverted" to Islam.
Stop using the stack to maintain your program state.
Sorry, I can't get behind that approach.
The most important thing for a server app, up 24/7, is that it is CORRECT. Programmed correctly, proven correct. The easier this is, the faster we can ship and upgrade with confidence. Breaking your application down, you may find that certain problems are best solved with one programming technique or another. Perhaps one search is best modelled with recursion. So do it that way. If you did it without recursion, maybe you could wring a bit more performance out of it, but let's just make it work CLEARY, CORRECTLY first. Optimize later. Anyone from a CS, especially functional, background will naturally see certain (not all, I hope!) problems as falling out of recursion. Recursion requires using the stack to maintain program state. And it's the right thing to do in many cases. Optimize later.
...around poorly designed operating systems where threads are slow. The cool thing about 2.6 is that there now is one less motivation for using such kludges.