Go for the low-hanging fruit first.
1. Pick hardware that suits your needs...
For example, if you have a LARGE transaction processing database
then your disk seeks and writes are going to be a big issue.
In this case you would do well to invest in a Hardware Raid
controller with battery backed write cache and consider RAID 10.
Or, if your server is a Web Application Server, (a "slashdot"
like server, or ecommerce server) then your CPU and RAM are
going to make a lot of difference since you can probably keep
most everything cached in RAM and your bottleneck will be CPU
for all the PHP and PERL and APACHE stuff.
If your server is doing file sharing, then your NIC's are all
important and you will want to carefully choose your Network
architecture (switches, NIC's) and pay special attention to your
Layer 0,1,2 setup.
2. Make sure you have the latest BIOS and firmware installed for all
your hardware. (many a sys-admin I have seen not do this crucial step).
Make sure you have installed all the latest recommended patches and
"errata". Get on the mailing list for your hardware vendors and
software vendors announcements.
3. Read all the fine documentation for the services that you are
running. You may find that by turning off "fsync" in a config file or by
turning of reverse-lookups, or adding a "-" in the syslog.conf, or
setting noatime in fstab, you are making a tradeoff in logging or worst
case scenario disaster preparedness that you can live with, but in
exchange you can get up to a 10 fold increase in performance.
4. Carefully examine the processes that *YOU* write. CGI programs, SQL
queries, SCRIPTS are often the bottlenecks in things and often they are
written very well, but are just not doing it the most efficient way. I
have seen a developer think about what is being acheived and suddenly
rewrite an app and get a 90% reduction in some critical resource usage
like Disk or Network or CPU utilization by changing a couple of
algorithms or the sequence of (if then) statements.
5. Examine Kernel parameters like shared memory segments, bdflush
parrameters, and the priorities of your various processes (you might be
able to "nice" some background processes).
Stripping your box of unnecessary software and removing lots of kernel
module options may make it boot faster, and may make it more secure in
certain scenarios, and it will definitely save a few MB or GB of disk
space and a few KB of RAM, but in most every case I have seen makes very
little dents in runtime performance.
After you have done these things then you need to consider what your ROI
is for further tweaking. Often times tweaking to the nth degree causes
scalability and maintainability issues in the future and so it is easier
to think about a scaling methodology that involves bigger or broader
server infrastructure, and that will be cheaper in the long run than
trying to tweak the kernel config.
On Thu, 2002-12-05 at 17:31, Søren Neigaard wrote:
> My Redhat will be a server, and not a workstation, and therefore I
> guess I can remove some of the services starting at boot time, or?
>
> One thing I found in my dmesg was this: "VFS: Diskquotas version
> dquot_6.5.0 initialized". I don't need diskquotas so can't I just
> remove it somehow? Or am I going at it the wrong way?
>
> Any pointers to things that I should stop/remove from the standard
> install?
>
> --
> Med venlig hilsen/Best regards,
> Søren Neigaard mailto:[EMAIL PROTECTED]
> --
> "Programming today is a race between software engineers striving to build bigger
>and better idiot-proof programs, and the Universe trying to produce bigger and better
>idiots. So far, the Universe is winning."
>
>
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
