Sudo Make Install

Yep title says it all, you can actually monitor individual disk performance with tw_cli.

First we need to enable performance monitoring:

tw_cli /c0 set dpmstat=on

Now we will show the information its providing.

tw_cli /c0 show dpmstat  type=ra
Drive Performance Monitor Configuration for /c0 ...
Performance Monitor: ON
Version: 1
Max commands for averaging: 100
Max latency commands to save: 10
Requested data: Running Average Drive Statistics

 Queue           Xfer         Resp
Port   Status           Unit   Depth   IOPs    Rate(MB/s)   Time(ms)
------------------------------------------------------------------------
p0     OK               u0     22      23      0.479        11
p1     OK               u0     24      93      1.344        12
p2     OK               u0     25      82      0.720        14
p3     OK               u0     24      83      1.108        16

BE SURE TO TURN OFF PERFORMANCE MONITORING WHEN YOU ARE DONE!

tw_cli /c0 set dpmstat=off

Different performance results:

This command only applies to 9000 series SX/SE/SA controllers, except for
type=ext, which applies only to SE/SA models.

This command allows you to request drive statistics of the specified type for
the specified port. These statistics can be helpful when troubleshooting
performance problems.

type= specifies which statistics should be displayed. The options are: inst for
Instantaneous, ra for Running Average, lct for Long Command Times,
histdata for Histogram Data, and ext for Extended Drive Statistics.

inst (Instantaneous). This measurement provides a short duration average.
ra (Running Average). Running average is a measure of long-term averages
that smooth out the data, and results in older results fading from the average
over time.

ext (Extended Drive Statistics). The extended drive statistics refers to
statistics of a drive’s read commands, write commands, write commands with
FUA (Force Unit Access), flush commands, and a drive sectors’s read, write,
and write commands with FUA.

lct (Long Command Times). This a collection of the commands with the
longest read/write response time.

histdata (Histogram Data). The histogram categorizes the read/write
execution times and group them together based on time frames.

For whatever reason they seem to have left out some important steps for a successful upgrade, so here you go:

wget https://fedoraproject.org/static/97A1071F.txt -O /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-primary
yum update fedora-release --releasever=14
yum --releasever=14 update --skip-broken -y

After you reboot run
rpm -qa | grep -v fc14 | xargs yum -y update

If anyone at the Fedora group is paying attention.. add this crap to the wiki.

http://fedoraproject.org/wiki/YumUpgradeFaq#Fedora_13_-.3E_Fedora_14

At Beyond Hosting we have a lot of customers who use CSF (Config Server & Firewall)  after about 30 installations of CSF the md5 checker can really cause problems for iowait.   So below is a script to check all the files for the setting of the md5 checker,  you can adapt this to check any file really.

for i in /vz/private/*
do grep "LF_INTEGRITY" $i/etc/csf/csf.conf
echo $i
done

Here’s the htop I’ve came up with over several years.

Simply create a “.htoprc” in your home folder with the below contents.

# Beware! This file is rewritten every time htop exits.
# The parser is also very primitive, and not human-friendly.
# (I know, it's in the todo list).
fields=0 48 17 18 38 39 40 2 46 47 49 1
sort_key=46
sort_direction=1
hide_threads=0
hide_kernel_threads=1
hide_userland_threads=0
shadow_other_users=0
highlight_base_name=0
highlight_megabytes=1
highlight_threads=0
tree_view=0
header_margin=1
detailed_cpu_time=1
color_scheme=0
delay=15
left_meters=Hostname Tasks LoadAverage Uptime Memory Memory Swap CPU CPU
left_meter_modes=2 2 2 2 1 2 1 1 2
right_meters=AllCPUs
right_meter_modes=1

Cool title right? Recently at Beyond Hosting we had a server get hard powered off while it was doing a raid array rebuild and for whatever reason it corrupted a ton of data, surprising right? Thank a singlehop DC ‘tech?’..

Okay well here’s how you do it.
First create a list of all the files that are SCREWED.

rpm -V -a > rpm.verify

Now reinstall them with yum, hopefully your yum/rpm still works..

cat rpm.verify | grep -v local | awk '{print $2}' | \
xargs rpm -q --whatprovides | sort | uniq | grep -v "no package" | \
xargs yum -y reinstall

At this point restart and hopefully everything that isn’t a configuration or user generated file is fixed.

I have just completed a Windows 2008 Server Standard install and configuring various areas of the server. One configuration that I always turn off is IE ESC, or Internet Explorer Enhanced Security Configuration.  This is an easy step so I thought I would post this up to the blog for future reference.?

To do this with Windows 2008 Server:

• Open Server Manager
• Locate the area of Security Information as shown below:

• Click the option Configure IE ESC

You will be shown the configuration window as shown below:

I have selected to turn OFF the IE ESC just for administrators on this server install. To complete simply click OK.

I just saved you from wanting to format the server with a nice clean install of Fedora….

An easy way to identify what process is generating your IO Wait load is to enable block I/O debugging. This is done by setting /proc/sys/vm/block_dump to a non zero value like:

echo 1 > /proc/sys/vm/block_dump

This will cause messages like the following to start appearing in dmesg:

bash(6856): dirtied inode 19446664 (ld-2.5.so) on md1

Using the following one-liner will produce a summary output of the dmesg entries:

dmesg | egrep "READ|WRITE|dirtied" | egrep -o '([a-zA-Z]*)' | sort | uniq -c | sort -rn | head
    354 md
    324 export
    288 kjournald
     53 irqbalance
     45 pdflush
     14 portmap
     14 bash
     10 egrep
     10 crond
      8 ncftpput

Once you are finished you should disable block I/O debugging by setting /proc/sys/vm/block_dump to a zero value like:

echo 0 > /proc/sys/vm/block_dump

Another cool method with a perl script: http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/

It’s important to keep your MySQL tables repaired and optimized, simply add the below command to crontab.

crontab -e

@daily mysqlcheck --all-databases -B -e --auto-repair --optimize

You will need to provide your MySQL root details in .my.cnf

[client]
user="root"
pass="password"

Alex actually showed me this a while ago but its a good bit of information.

The default Apache settings that cPanel sets upon install are definitely something that can be improved on. With a few small tweaks, the efficiency with which Apache runs with can be greatly improved.

To start with, lets go ahead and open the Apache configuration file:

vim /usr/local/apache/conf/httpd.conf

This list is a composite of the settings we will be reviewing from fresh install on a cPanel server:

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 15

MinSpareServers 5

MaxSpareServers 10

StartServers 5

MaxClients 150

MaxRequestsPerChild 0

Please note, the settings that we will review in this article are by no means a complete list

of tweakable options in the Apache configuration file. The settings we will be focusing on are

the ones that control how Apache handles webpage requests.

Timeout

Timeout 300

Usually this value doesn’t require editing and a default of 300 is sufficient. Lowering the ‘Timeout’ value will cause a long running script to terminate earlier than expected.

On virtualized servers like VPS servers, lowering this value to 100 can help improve performance.

KeepAlive

KeepAlive On

This setting should be “On” unless the server is getting requests from hundreds of IPs at once.

High volume and/or load balanced servers should have this setting disabled (Off) to increase connection throughput.

MaxKeepAliveRequests

MaxKeepAliveRequests 100

This setting limits the number of requests allowed per persistent connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed.

It is recommended to keep this value at 100 for virtualized accounts like VPS accounts. On dedicated servers it is recommended that this value be modified to 150.

KeepAliveTimeout

KeepAliveTimeout 15

The number of seconds Apache will wait for another request before closing the connection. Setting this to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.

It is recommended that this value be lowered to 5 on all servers.

MinSpareServers

MinSpareServers 5

This directive sets the desired minimum number of idle child server processes. An idle process is one which is not handling a request. If there are fewer spareservers idle then specified by this value, then the parent process creates new children at a maximum rate of 1 per second. Setting this parameter to a large number is almost always a bad idea.

Ajusting the value for this setting to the following:

Virtualized server, ie VPS 5

Dedicated server with 1-2GB RAM 10

Dedicated server with 2-4GB RAM 20

Dedicated server with 4+ GB RAM 25

MaxSpareServers

MaxSpareServers 10

The MaxSpareServers directive sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes.

The MaxSpareServers value should be set as double the value that is set in MinSpareServers.

StartServers

StartServers 5

This directivesets the number of child server processes created on startup. This value should mirror what is set in MinSpareServers.

MaxClients

MaxClients 150

This directive sets the limit on the number of simultaneous requests that will be served. Any connection attempts over the specified limit will be queued. Once a process is freed at the end of a different request, the queued connection will then be served.

For virtualized servers such as VPS accounts, it is recommended to keep this value at 150. For all dedicated servers the recommended value for this setting is 250.

MaxRequestsPerChild

MaxRequestsPerChild 0

This directive sets the limit on the number of requests that an individual child server process will handle. After the number of requests reaches the value specified, the child process will die. When this value is set at 0, then the process will never expire.

Some Recommended Values

Virtualized server, ie VPS 300

Dedicated server with 1-4GB RAM 500

Dedicated server with 4+GB RAM 1000

Over the past few months we tried some advertising with AT&T advertising solutions,  lets just say they are built from bullcrap and love to talk it!

https://beyondhosting.net/blog/2010/08/our-att-advertising-solutions-horror-story/