SET GLOBAL general_log = ‘ON’;
SET GLOBAL log_output=’table’;

ALTER TABLE foo ORDER BY something;
does what OPTIMIZE does (but in a totally different way), plus clusters data based on the ORDER BY. In a few cases, this can be quite beneficial. Here’s an example:
* Table is bigger than will fit in cache.
* Table has two ways to look at it, one is date oriented, the other is by some “key”.
* There are hundreds of rows for each key (one per day)
* There are thousands of keys for each day.
* Data is coming in daily — That is, new rows are appended to the table and/or filling in holes left by deleted rows.
* Your main query is SELECT … WHERE key = ‘…’ — that is, one row per day.

Normally the rows for that SELECT will be quite scattered, and because of the size of the table, it will take a lot of disk hits.

The ALTER table will rearrange the rows so that the SELECT will find all the rows for the ‘key’ clustered in a few blocks, hence much less disk I/O.

IF this use of ALTER feels right for you, I recommend doing it monthly. Watch out: It could take hours (remember, it is bigger than will fit in cache).

For small tables (say, <100K rows), the ALTER is reasonably fast, but gives only limited improvement.

I have felt the need for the ALTER in less than 1% of the tables I have studied.

-bash-3.1$ pg_ctl stop
waiting for server to shut down……………………………………………………… failed
pg_ctl: server does not shut down

Sometimes postgres does not want to shutdown by just issuing a pg_ctl stop as the postgres user. User might feel the need to “kill -9″ the postgres processes however this could be dangerous for PostgreSQL. Instead of trying to kill the PID follow the directions below in an attempt to stop postgres in an organized fashion.

1. Attempt Normal Stop: bash-3.1$pg_ctl stop
2. Attempt Smart Stop: bash-3.1$pg_ctl stop -m s
3. Attempt Fast Stop: bash-3.1$pg_ctl stop -m f
4. Attempt Immediate Stop: bash-3.1$pg_ctl stop -m i
The immediate stop almost always ends up stopping postgres if you are having trouble in stopping the processes. If the immediate stop does not work the issue should be investigated before attempting to kill -9 the PID.

Try this:

find . -name ‘*’ -exec rm {} \;

What to force it so it does not ask you y/n for each file?

find . -name ‘*’ -exec rm -f {} \;

To remove/delete only directories just add a ‘type’ flag to find…

find . -name ‘*’ -type d -exec rm {} \;

First:
sudo apt-get install linux-image-

This will give you all current options for a new linux kernel image.

Next do the same with the headers!
sudo apt-get install linux-headers-

Make sure you do your headers too!!!

find -type f -name ‘*.rar’ -exec unrar -pPASSWORD x {} \;

find /path/to/files/* -mtime +90 -exec rm {} \;

Just replace the 90 with the number of days old you want to delete.

You can also pipe it into a log file:

bash -c ‘date;find /path/to/files* -mtime +5 -exec rm -v {} \;;date’ > ~/mylog

The first thing I find is how to see how many processes I have running:

ps auxww | grep ^postgres | wc -l

ps auxww | grep ^postgres

The first shows you how many process are running, and the second gives you more detail. So I now I had a little bit better understanding of what was going on. I could see how many postgres process I had at any one time. But that did not help me figure out which queries and what app was causing the problems.

I googled some more and figured out how to query the active queries.

So I run this query against the stats database:

SELECT count(*) as cnt, usename, current_query FROM pg_stat_activity GROUP BY usename,current_query ORDER BY cnt DESC;

But I get “<command string not enabled>”; so more googling and I found I need to change a setting in the postgresql.conf and set the stats_command_string = true.

Ok with this done I was able to run the query above and find 1 single query that was getting repeated over and over again hundreds of times and was taking 8-10 minutes to finish, and even longer as the queries stacked up.

On further inspection, this one query is supposed to be memcached, its hit on every page of a site and should cache once and never hit the database again, but its not. Some times it does and things run great, other times it continues to not find it in cache and hit the database.

We could not figure out why this particular query out of the hundreds we store in memcache is not being cached properly. So we cache it the old fashion way in file, till we can work out why it won’t cache in memcache. Once its cached again properly, ir improperly in this case, Postgres starts working properly again. No more high connections and no more app failures.

The end, or is it? Now we have to figure out why it won’t cache in Memcache properly.

su -s /bin/sh apache -c “whoami”

The code

<?php

$email = "someone@example.com";

if(eregi("^[_a-z0-9-]+(.[_a-z0-9-]+)*@[a-z0-9-]+(.[a-z0-9-]+)*(.[a-z]{2,3})$", $email)) {

  echo "Valid email address.";

}

else {

  echo "Invalid email address.";

}

?>