Posted by & filed under Control Panels, Webmin.

Official Ubuntu circle with wordmark. Replace ...

Image via Wikipedia

So lately I have had a few servers go down. Which has made me decide to switch things up a bit. Some decisions I made just for the hell of it. I was using CentOS linux for my servers. I don’t know why. It always seemed to be there at the top of every hosting companies choices, so I just thought that meant it would be better. But with my latest servers, I have switched to Ubuntu because I have an Ubuntu home computer now and makes it kind of nice knowing where everything is on either, since they are about the same.

I also realized that for my server uses (I don’t do any hosting of other people sites unless it is CMS hosting like WordPress), Virtualmin was overkill. I didn’t need all the extra files and functions. I didn’t need a virtual host for every domain if all I was going to do in the end was stack everything on top of one WordPress installation. Most of my servers run WordPress. A few will eventually run sites on Turbogears. Each one of these can handle subdomain and domain mapping if I just send the wildcarded domains at them.

So no more virtualmin in my installs. Only Webmin. I would go without a control panel all together, but I don’t trust my ability to run a whole server with a SSH window. I like seeing that Apache, MySql, my Firewall and various other things are running. I also like having access to change things from anywhere. Everyone has a browser, but not everyone has SSH or Putty hanging around.

So that is about all I have to say about that. This experience with exploding servers has given me a lot of notes and a lot of potential posts. And hopefully I can get them up here to help others.

Enhanced by Zemanta

Posted by & filed under MySql.

Image representing MySQL as depicted in CrunchBase
Image via CrunchBase

In my experience, everything else about optimizing a LAMP server is pretty easy. But MySql is a bitch. Most of the times I run into slow running database driven sites, I have to go no further than MySql. And if your MySql installation is not optimized, I can tell you without a doubt that until it is, speeding up any other part of your site isn’t going to make much of a dent.

I do have one site running only on Webmin and Webmin does nothing to MySql settings and MySql out of the box is not optimized. It should be tweaked to the needs of your site. But that really is the topic for a whole ‘nother blog, really. MySql can be a very complex mess.

But there is a tool called MySql Tuner that will help you optimize your MySql installation. At least it will give you places to look.

To use it, simply Putty into your server and type the following two lines:
wget mysqltuner.pl
perl mysqltuner.pl

After that is done, your Putty window should spit out text similar to this:

wget mysqltuner.pl
--2010-11-27 07:18:22-- http://mysqltuner.pl/
Resolving mysqltuner.pl... 174.143.142.58
Connecting to mysqltuner.pl|174.143.142.58|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://mysqltuner.pl/mysqltuner.pl [following]
--2010-11-27 07:18:23-- http://mysqltuner.pl/mysqltuner.pl
Reusing existing connection to mysqltuner.pl:80.
HTTP request sent, awaiting response... 200 OK
Length: 39054 (38K) [text/plain]
Saving to: `mysqltuner.pl'

100%[======================================>] 39,054 --.-K/s in 0.1s

2010-11-27 07:18:23 (271 KB/s) - `mysqltuner.pl' saved [39054/39054]

[root@hostserver tmp]# perl mysqltuner.pl

>> MySQLTuner 1.0.1 - Major Hayden
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login:
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive +BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 295M (Tables: 321)
[--] Data in InnoDB tables: 1M (Tables: 7)
[!!] BDB is enabled but isn't being used
[!!] Total fragmented tables: 38

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 10m 40s (41K q [9.728 qps], 782 conn, TX: 117M, RX: 9M)
[--] Reads / Writes: 63% / 37%
[--] Total buffers: 40.0M global + 2.7M per thread (300 max threads)
[!!] Maximum possible memory usage: 846.2M (165% of installed RAM)
[OK] Slow queries: 0% (72/41K)
[OK] Highest usage of available connections: 5% (15/300)
[OK] Key buffer size / total MyISAM indexes: 2.0M/50.3M
[OK] Key buffer hit rate: 99.4% (716K cached / 4K reads)
[OK] Query cache efficiency: 25.9% (6K cached / 26K selects)
[!!] Query cache prunes per day: 26898
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 543 sorts)
[!!] Joins performed without indexes: 328
[!!] Temporary tables created on disk: 32% (326 on disk / 994 total)
[OK] Thread cache hit rate: 98% (15 created / 782 connections)
[OK] Table cache hit rate: 96% (149 open / 155 opened)
[OK] Open file limit used: 11% (272/2K)
[OK] Table locks acquired immediately: 97% (31K immediate / 31K locks)
[OK] InnoDB data size / buffer pool: 1.6M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Add skip-bdb to MySQL configuration to disable BDB
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_size (> 12M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)

First you get the stats and the metrics:

[OK] is obviously good.

[!!] is an issue and

[--] is just information

And after that comes the suggested fixes. The lines that scared me was “*** MySQL’s maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables ***”. Not much I could do about that expect moving to another server. So I was going to try to see what I could do with the rest. It was taking 90% of the processor at the time.

Running OPTIMIZE TABLE always helps a bit but it is not a really big issue causer.

And really, this did tell me a lot to find a few issues. Of course, if you have anything other than a very basic PHP/MySql site, suggestions like “Adjust your join queries to always utilize indexes” will take a while to optimize. Well, not if you spend just a little time watching your MySql connections. Usually connections are there and gone quickly, but if you see a few hanging around for a while, you should get a listing of what query is being run at that connection. In mine, I saw JOINS in the queries so I went to make sure the joined columns were indexes. One was not. I also happened to see me using LIKE when = would do and NOT LIKE when <> would do.

I quickly found the files the queries were being run from and fixed the issues. Now I can’t catch a connection hanging around long enough to give me another query to optimize. Both of these were queries i never should have written, but since I am self taught, it took me a while to learn MySql query optimization. It is not the type of thing you learn in beginners books.

The rest of the steps involve editing the MySql Configuration file like so:

skip-bdb
query_cache_size=12M
tmp_table_size=32M
max_heap_table_size=32M
join_buffer_size=128K

And I will have to say that sped up things quite a bit with no more queries hanging around forever. I had done some MySql tuning manually with decent success but I will have to say having the MySqlTuner script around helped a whole lot.

Enhanced by Zemanta

Posted by & filed under Virtualmin.

Logo of the Apache Software Foundation
Image via Wikipedia

This started right after I added an addon domain in Virtualmin. Something that I had already done with a couple of Virtualmin installations, so it sort of threw me for a loop. I like to stack a lot of WordPress domains on one installation and with Virtualmin it is easy.

Suexec is a CGI wrapper that allows virtual hosts each run php safely. If you are running hosts with multiple users, I would suggest fixing the issue for safety’s sake. You can find details here.

If you are only using Virtualmin like I do: to control a lot of domains from one panel, then you can stop the issue before it starts by not using SuExec.

You can do this by going to Virtualmin->System Settings(the lower menu)->Server Templates->Apache Website. Then find “Automatically add appropriate SuExec directive?” and check “no” and save these settings.

You can also cause this issue by setting a user’s folder to the group “apache”. I found this out the hard way and it set me an hour behind.

I do this in the web folder that I install WordPress into. If not, I an stuck with installing plugins and themes with FTP credentials instead of the quicker WordPress ways. It still beats using an FTP program but hey, might as well make it right.

Well, in Virtualmin, the html folder is in the user folder. So I set the user folder and everything under it to the group “apache”. Quick fix: change the user folder back to the same group as the user, then set the html folder and all underlying folders to the group apache.

Enhanced by Zemanta

Posted by & filed under SSH, Virtualmin.

PuTTY running a session on Windows Vista.

Image via Wikipedia

Other Posts That May Help You, Before Reading This One

  • What is SSH?
  • Using Putty

1. Updating Your Server with Yum

Open up Putty and log into your new server at the IP address with the root server credentials you were given after signing up for it.

Once you have an SSH window open, type the following in. If you want to you can copy it. To paste into the SSH window, use the right click of your mouse.

yum update

After you type that in and hit enter, yum will run it’s check and tell you how many updates are available. There always seems to be a lot. The server I am setting up to write this post had 60 updates to run.

The server will ask you if you want to proceed. Type a “y” and hit enter.

This part may take a while.

2. Installing Perl

yum install perl

On my Woo server, I don’t have to run this. Perl is already installed. But it is necessary for Virtualmin, so paste the line above in and hit enter. If you need Perl, it will ask you the y/n question again. If you don’t, it will tell you there is nothing to install.

3. Getting and Installing Virtualmin

This first line will get you the latest install script from the Virtualmin website. Type or copy and paste this into your SSH window and hit enter

wget http://software.virtualmin.com/gpl/scripts/install.sh

This next line will run the install script. Now this part will take the longest. Virtualmin comes with a lot of stuff. It was during this part that I wrote most of this post.

/bin/sh install.sh

Once this is done though, you will have a Virtualmin installation and you can login in with your server’s root username, which actually may be “root” and your password at

https://YOURIPADDRESS:10000

Where you should be greeted by the following

4. The Virtualmin Post Configuration Wizard

This post-installation wizard allows you to configure Virtualmin optimally for your system. You can make selections depending on whether you want to host websites, email or databases, and based on your system’s memory and CPU power.

To continue, click the Next button below. To skip it and use the default settings, click Cancel.

Clicking “Next” here will bring you to the memory usage screen. This will have two sets of radio buttons:

  • Preload Virtualmin Libraries – I choose no on this option because the only one using my Virtualmin’s will be me. I am not a hosting provider. If you are and have memory to spare you may want to choose “yes”. It will use about 20 Megs of RAM.
  • Run Email Domain Lookup Server – Again I choose no, because I use Gmail. Your choice is up to you. Choosing yes will cost you about 35 Megs of memory.

Clicking “Next” again will bring you to a screen where you are asked yes or no about running CLAMav Server Scanner. It is a good thing to answer yes if you are running an email server. That way CLAM can scan your email for viruses. But it will cost you 100 Megs of RAM.

After you click “Next” again you will be asked about SpamAssassin. Again, most likely a necessity if you are using email. But it will cost you another 30 Megs.

Clicking next will bring you to a screen where you are asked if you want to run MySql and/or PostGreSql Server. Everything I run uses MySql, so I check yes on that one and no on PostGre.

Clicking next will bring you to a screen to set your MySql password.

Clicking next again will bring you to last screen and then you will have the option to check your configuration.

And you are done!

You can now start setting up domains.

Enhanced by Zemanta

Posted by & filed under Virtualmin.

This may apply in my own specific situation, but it took a while for me to find the right answer and fix it. About 3 hours. And the fix took only a couple of seconds. Which means its ripe for a blog post. And please, if you have the same issue and my fix does not work, leave a comment. Or if you fixed this issue another way, chime in and help others out.

I am not quite sure what caused the issue in the first place. I was using the W3 caching WordPress plugin with APC and the server was crawling a lot slower than it should for a day or so. I went to login on Virtualmin on port 10000 to check out what was slowing things down and Virtualmin was gone. The last time I was in there, my memory usage was peaking.

Now the most obvious thing would be something crashed. But all my sites were up. I could get to my FTP. I logged in via SSH and virtualmin was running. WTF, seriously.

Now everyone tells you to check your firewall. There was no firewall on port 10000 before and it should not have just changed overnight. I rebooted my VPS and I still could not login to virtualmin on port 10000.

I even ran a check on Virtualmin through SSH and it told me this:

“Virtualmin is configured to setup DNS zones, but this system is not setup to use itself as a DNS server”.

And that had me on a wild google chase for a while that ended nowhere.

Finally the answer was as simple as running /etc/webmin/start in SSH with Putty.

I made that bold for those of you who don’t feel a narrative is necessary to fix a problem.

I guess Virtualmin can stay running even when Webmin crashed. And I am guessing it either crashed two times in row. Like I said, I rebooted. Or it’s “Run At Bootime” setting isn’t working. You can find this on the Webmin side of Virtualmin. Go to Webmin->Webmin Configuration.

Run Webmin At Boot Time

Run Webmin At Boot Time

I am not sure what happened but I can speculate. Running caching is a tradeoff. It is meant for sites that get a lot of traffic and spikes of traffic. If a site gets 400 visitors a day, most likely, no more than two to three people will be on the site at any one time. Really no need for caching unless you are running WordPress with a lot of plugins. I went back to using the page caching instead of APC. Using APC trades memory overhead for page speed. This is great if you have a lot of memory to spare.

On smaller VPS’s, running Memcache or APC could use up every last bit of memory you have to spare and your pages will start loading slow anyway because your VPS is bogged down. And the only time computers or servers resemble drunk humans is when you are pushing there limits. Things crash. Things get forgotten.

And like I said, leave a comment if this fix did not work for you. Or if you have another solution.

Enhanced by Zemanta