Find the answer to your Linux question:
Results 1 to 9 of 9
....when a request comes in, does the interrupt handler actually input anything from the interface into memory? This is why crashes under load must be caused, right, because the server ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux User
    Join Date
    Mar 2013
    Posts
    254

    Why does a server CRASH under load?


    ....when a request comes in, does the interrupt handler actually input anything from the interface into memory? This is why crashes under load must be caused, right, because the server runs out of RAM....?
    My first question is, is this how Linux works? And secondly, what's being done about it, IF it's true?
    Linux should be above this, no?

  2. #2
    Linux Engineer
    Join Date
    Dec 2013
    Posts
    1,034
    Linux is the host operating system. While it a computer is sometimes referred to as a server, a server is actually software that is one side of a client/server pattern. A computer that is primarily being used to run server software is sometimes referred to as a server but in the context you are using it isn't the server but the platform for the operating system which is the host for the server.

    Further delineating the process, we have the network interface card (nic), which also is hosted by hardware and operating system in tandem. To grossly simplify: when it receives a packet it pushes it onto a queue for the host. The driver will have to reserve memory for it and issue an interrupt. The operating system will read the identifying information on the packet and inform the application that is waiting for it that it can now read some data. The application will reserve some memory to copy the data into. After processing the data any number of possible actions may require more memory to be reserved, and other memory to be released. Usually a server will need to respond. In the case of a web server it may be loading a file into memory and passing it to the network interface.

    There can be many reasons for a crash - including bugs in the software. Under loads that are too heavy a machine may run out of memory and the software must in someway handle the situation. Generally speaking though, it is an issue that needs to be handled by the architecture of the application and/or the hardware architecture. There have been improvements in the communication between kernel and application space that have improved Linux' ability to handle network traffic but there are limits to what can be done in that space. Bugs in the software are a condition of the complexity of software. Architectures exist for handling enormous loads but not all applications will be designed with that in mind.

    It is a complex subject.

  3. #3
    Linux User
    Join Date
    Mar 2013
    Posts
    254
    Quote Originally Posted by gregm View Post
    The driver will have to reserve memory for it and issue an interrupt.
    I thought the driver was called by the interrupt.....? i.e. it's code is the interrupt handler....? Am I somehow getting this wrong?

  4. #4
    Linux User
    Join Date
    Mar 2013
    Posts
    254
    Quote Originally Posted by gregm View Post
    Bugs in the software are a condition of the complexity of software. Architectures exist for handling enormous loads but not all applications will be designed with that in mind.
    They've been making Apache for what, 15 years now? Surely they must have got it pat by now? Talking of which, which of the softwares such as nginx etc. is the best for heavy load?


    And,...... which architectures?

  5. #5
    Linux Engineer
    Join Date
    Dec 2013
    Posts
    1,034
    I think strictly speaking the device issues an irq (interrupt request) when it is ready to send or receive and the kernel informs the registered isr's (interrupt service requests).

  6. #6
    Linux Engineer docbop's Avatar
    Join Date
    Nov 2009
    Location
    Woodshed, CA
    Posts
    902
    It boils down to tuning your system for the services you are running. We used nginx at the last place I was at and it is light weight compared to Apache but had to montior and tune it, learn how it worked with our software. There are no absolute answers its all about learning the software, its configuration parameters, and then how it works on your hardware configuration and your software. If it was install and forget then that there would be no need for SysAdmins.

  7. #7
    Linux Engineer
    Join Date
    Dec 2013
    Posts
    1,034
    Quote Originally Posted by resetreset View Post
    They've been making Apache for what, 15 years now? Surely they must have got it pat by now? Talking of which, which of the softwares such as nginx etc. is the best for heavy load?


    And,...... which architectures?
    Apache does what it does well. There are servers designed to handle heavier loads, lighttpd for one, they may not do some of what httpd does; if you want to use Apache's httpd and your load is greater then what it can handle you can use a load balancer and caching etc.

  8. #8
    Linux User
    Join Date
    Mar 2013
    Posts
    254
    Are there any HARDWARE architectures which are great at webserving othe r than x86, and priced still not too high?

  9. #9
    Linux Engineer
    Join Date
    Dec 2013
    Posts
    1,034
    Quote Originally Posted by resetreset View Post
    Are there any HARDWARE architectures which are great at webserving othe r than x86, and priced still not too high?
    I see used Sun and IBM systems from time to time. Sun has systems using SPARC processors and IBM has ARM, both of which are RISC processors. There was a time when they were better systems but advances if CISC chips has probably negated any advantage. Linux is as good an operating system now as Solaris or AIX. I don't know if there is a Linux for SPARC or not. RISC chips do use less power then CISC.

    Ultimately the chipset probably doesn't make much difference to a web server. The server software, network card and network topography are going to be the big factors.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •