Find, analyze, and kill long-running queries
When mytop starts, it sorts threads by the Time column—that is, how long the thread has been in that state. Those that have most recently changed appear at the top of the screen. To locate long-running queries, first remove all idle threads from the display by pressing i, then reverse the sort order by pressing o. The resulting display will show the longest running queries at the top of the screen.

Once you’ve located a long-running query, you can obtain the full query by pressing f and entering the thread ID when prompted. When looking at the full query, you can ask MySQL to explain the query by pressing e. Or you may kill the query by pressing k and supplying the thread ID.[1]

[1] In MySQL 3.23 and 4.0, killing a query also terminates the client’s connection to the server. In other words, it kills the connection, and the query dies as a byproduct of that.

Determine what type of queries MySQL has been running
It’s often useful to know whether MySQL is running more SELECT or more INSERT queries. Maybe you suspect an application is misbehaving, or perhaps you’d simply like to compute your server’s typical read to write ratio. In mytop’s thread view (Figure B-1), it displays the percentage of SELECT, INSERT, UPDATE, and DELETE queries. On the right side of the header, you’ll see something like this:

Se/In/Up/De(%): 61/30/02/05

…  63/07/12/10
The first line means that, overall, 61% of the server’s queries are SELECTs, 30% are INSERTs, 2% are UPDATEs, and 5% are DELETEs. The second line displays values that apply to the last refresh interval (5 seconds by default) only. The two together can give a quick feel for what your server has been doing recently and how that compares to the longer term average.

If you want more detail, press c to switch mytop into command view. There you’ll find detailed counts and percentages for each type of command or query executed. The first column of numbers summarizes overall counts (since the server was started or counters reset), while the second set of numbers reflects the last refresh interval only.

Kill a group of queries
Use mytop’s “super-kill” feature by pressing K. You’ll be prompted for a username, and mytop will then kill all of that user’s threads. In the future this may be extended to evaluate more complex expressions, such as killing all nonidle threads from a given hostname or IP address.

Limit the display to a particular user or host
You can ask mytop to filter out all threads except those from a given host or those owned by a given user. If you press u, mytop prompts for a username to filter on. Similarly, pressing h allows you to provide a hostname or IP address which is used to filter the display. If you supply both, mytop restricts the display based on both criteria.

To clear the filtering, you can press F to remove all filters at once. Otherwise, you can use the u or h keys to remove either of the filters manually.

Symtoms:

- Apache crashed every 5 minutes. top command shows a high number of ilde httpd requests (negative priority)

- mySql kept saying too many connections

- Reboot server comes to file system failure. Use fsck to get it back online but problem persits.

Finally:

- Enable http_access log on httpd.conf to see where it is because of DOS attack. It turned out yes. The IP 79.125.40.218 which comes from Amazon data services send out a high number of GET request to our server.

- Ban the IP from httpd.conf : deny from 79.125.40.218. Voila, system is fine again.

We will consider using iptables to more effectively ban ips.

Thanks God. The server is up.

Biethet.com

The customer is not always right–so fire your wrong ones.

Jackasses have been in the news lately, with President Obama caught on an open mike observing that Kanye West was one after the rapper made a fool of himself at the recent MTV Video Music Awards. Jackasses are always with us in business too. Robert Sutton in his book (using a cruder term for the same sort of person) The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t, argues that talented yet disruptive employees always cause more harm than good. He says you need to either reform them or push them out. But what about when it’s not employees but clients who are difficult, who berate your team and make you waste time running around in circles? Should you just suck it up and make sure you hit the quarterly numbers? Or should you fire those customers?

Companies need to exceed the expectations of customers to create brand loyalty, as I wrote in “United Airlines Shows How Not to Run Your Business.” After all, it costs less to sell new products and services to current customers than to acquire new ones. But the old adage that the customer is always right is just plain wrong. Customers are not always right, and you should not always let them run all over you.

That might sound counterintuitive if your company is struggling just to scrape by in this difficult economic time, but you have to get rid of bad clients. Jackass clients, just like difficult employees, can destroy a business by destroying morale and diverting attention from growing the business. Cutting clients isn’t easy, especially if they’re big ones, but companies need to do it more often.

How do you know if you should fire a client? Look for these three signals:

First, too often executives, especially small business owners, spend so much time and energy servicing difficult clients that they’re unable to canvass for new business. Relying on just a few clients is a killer. Basing your whole business on one or two income sources is simply too risky. If you find yourself spending so much time and effort on one difficult client that you’re neglecting your other clients, or if you’re not able to search for new ones, then you know you have a problem.

Keep in mind the 80-20 rule. At most companies, about 80% of the revenue comes from 20% of the clients. If you find you’re spending too much time on an unproductive client, fire them. Analyze where you spend most of your time and effort. You’re likely to learn that you spend the most time on the least important clients. That’s because more important clients already trust you and are therefore easier to please.

Second, remember that if your company is like most, your employees are your greatest asset. A good management team can squeeze profits out of bad products, and a bad management team can kill even the best ideas. The key is to retain your best people. In the long run they will help you make far more profits than the one difficult client who may drive them away.

If your employees look haggard and even the go-getters among them hesitate to take on a new project with a particular client, it’s time to investigate. Sometimes an employee will leave a company because of unhappiness with day-to-day client work, rather than because of bosses or colleagues. This is especially true in service industries like law, medicine and accounting, where one spends more time with clients than with co-workers. It is terrible to work in an environment where the client makes your life miserable and your boss fails to back you up. Everybody wants to work in a humane environment where they feel valued and supported.

Bad morale also exhausts employees and makes them unable to think clearly and plot the best courses for future success.

Finally, life is short. While we all have to put up with difficult situations and people sometimes, you can’t let chronically difficult clients affect the health and well-being of your family. If your kids or significant other tell you you’re especially grumpy, then think about whether a client is causing your stress, and whether that stress is worth it. Most of the time it isn’t.

High-paying jobs and the resulting benefits like vacation homes, jewelry and gadgets are great, but at the end of the day, always remember why you work so hard.

cd /etc/mail
make stop

To start sendmail:

cd /etc/mail
make start

To restart sendmail:

cd /etc/mail
make restart

To get sendmail to regenerate aliases, the virtual user table and other stuff, run make on its own like so:

cd /etc/mail
make

After running “make” on its own, sendmail automatically reads all the files so you shouldn’t need to restart sendmail yourself at this point.

The header information from the Makefile in /etc/mail contains information about commands that can be passed to make. The top of this file is listed below.

# This Makefile provides an easy way to generate the configuration
# file and database maps for the sendmail(8) daemon.
#
# The user-driven targets are:
#
# all     - Build cf, maps and aliases
# cf       - Build the .cf file from .mc file
# maps     - Build the feature maps
# aliases - Build the sendmail aliases
# install - Install the .cf file as /etc/mail/sendmail.cf
#
# For acting on both the MTA daemon and MSP queue running daemon:
# start         - Start both the sendmail MTA daemon and MSP queue running
#                 daemon with the flags defined in /etc/defaults/rc.conf or
#                 /etc/rc.conf
# stop         - Stop both the sendmail MTA daemon and MSP queue running
#                 daemon
# restart       - Restart both the sendmail MTA daemon and MSP queue running
#                 daemon
#
# For acting on just the MTA daemon:
# start-mta     - Start the sendmail MTA daemon with the flags defined in
#                 /etc/defaults/rc.conf or /etc/rc.conf
# stop-mta     - Stop the sendmail MTA daemon
# restart-mta   - Restart the sendmail MTA daemon
#
# For acting on just the MSP queue running daemon:
# start-mspq   - Start the sendmail MSP queue running daemon with the
#                 flags defined in /etc/defaults/rc.conf or /etc/rc.conf
# stop-mspq     - Stop the sendmail MSP queue running daemon
# restart-mspq - Restart the sendmail MSP queue running daemon
#
# Calling `make' will generate the updated versions when either the
# aliases or one of the map files were changed.
#
# A `make install` is only necessary after modifying the .mc file. In
# this case one would normally also call `make restart' to allow the
# running sendmail to pick up the changes as well.


**********

As with most things, a logical and structured approach is the best way to go. Therefore I have put together 10 quick tips (in no special order) to help make your CSS coding as pain-free as possible.

1. Keep it Simple

This may sound obvious but if you find yourself using complicated coding to achieve your design then you should think again about whether the feature you need is really necessary or if you’re just thinking about your design and not your visitors. Too often designers get caught up in their own design and go to great lengths to produce a certain visual effect only to find later on that visitors find it either irritating or unusable.

Complex code is usually the result of muddled thinking. Plan your layout logically and work from the outside in and from the top down where possible. Look at what containers you will need and break jobs down into smaller parcels. I usually start with a page wrapper and then progress logically through the header, navigation, main content and footers etc trying to preserve the flow of the document as much as possible.

While good visual design is necessary to attract visitors you must still have good content and a usable and accessible site. If you find your html and css looks like spaghetti then have a re-think and see if you can simplify it. This will make it easier to maintain in the future and will often save code and bandwidth.

2. Don’t use hacks unless its a known and documented bug

This is an important point as I too often see hacks employed to fix things that aren’t really broken in the first place. If you find that you are looking for a hack to fix a certain issue in your design then first do some research (Google is your friend here) and try to identify the issue you are having problems with.

If you find its a known bug then 99% of the time there will be a known solution to this bug and you can safely use a hack if required knowing that you are fixing a bug and not just correcting bad coding.

I couldn’t count the number of times I’ve seen layouts using hacks when all that was needed was to control the default margins on the page (see next tip).

3. Take care of margins and padding on all elements that you use

All browsers apply default padding and margins to most elements and the amount they apply varies quite substantially. Therefore you need to explicitly control the padding and margins on all the elements you use.

This is covered in depth in this article “No Margin For Error”.

4. Avoid using too much absolute positioning

Most novices to CSS quickly latch on to absolute positioning because it is pretty straight-forward and does what it says on the box. However absolute layouts have a number of problems and the biggest problem of all is that absolute elements are removed from the flow.

This means that when you absolutely place an element then it has total disregard to whatever else is on your page. It will overlap whatever was in that position and will take no notice of other content at all. The result of too much absolute positioning is that you end up having to control everything with absolute positioning and makes for a very rigid and inflexible layout.

The most common problem encountered when using absolute positioning for two or three columns is “How to put a footer at the bottom of all three columns?” The answer is you can’t, unless you resort to scripting or use a fixed height for all three columns.

Instead you should look into using mostly static positioning, margins and floats to maintain the flow of the layout. Static positioning is the default and basically means no positioning at all and the elements just take up space in the normal flow of the document. If elements flow normally then they have a logical construction and one element follows another without having to position it at all. You can use margins to nudge elements into position or use floats when you want elements aligned horizontally.

5. Avoid “divitus”

Although “divitus” isn’t a real word it is now commonly used to refer to layouts that have too many divs and not enough semantic html. Semantic html means using the correct html element for the task in hand and not just using divs for everything. Divs are generic dividers of page content and nothing else. 99% of the time there will be an html tag perfect for the job in hand.

e.g. p,h1,h2,h3,h4,h5,h6,ul,ol,dl etc…

Use divs to divide the page into logical sections or when there is no better alternative. If your page is logically divided into sections that use id’s to identify each section then this will allow you to target inner elements in that section without having to over-use classes on each element

e.g. #top-section h1 {color:red}(see next tip on “classitus”).

A common misuse of divs can be found in the following example:

A lot of times the above code can simply be reduced to this:

As you can see, by using the correct html to describe the content you give your layout inherent structure and meaning without any extra effort.

6. Avoid “Classitus”

“Classitus” is another made up word similar to “divitus” (as explained above) and refers to the over-use of classes (or id’s) when in fact none are necessary. If your page is logically divided then you can target many specific elements without the need for millions of classes.

A common example of misuse of classes is shown below:

All the links have been given a class of .link in order to style them and is completely unnecessary. If we apply an ID or class to the UL instead, we can target all the anchors within that ul without having to add any extra classes at all.

As you can see we get the same effect and save considerably on mark-up and readability. A lot of times the ul may be unique in a section anyway and you can use the parent id without even having to add an id to the ul. (Remember that id’s are unique and can only be used once per page.)

7. Validate your code

Visit the validator at every opportunity and validate your css and html especially when learning something new. If you are new to html/css then validate regularly during development so that you can be sure the code you are using is correct; that will allow you to concentrate on getting the design right.

Do not wait until you have finished coding the design as you may be using features that are not appropriate and will result in a lot more work than necessary. Validating frequently will also catch simple errors like typos which will always creep into the code when you are not looking.

8. Rationalize your code

At every stage during development ask yourself whether you need that extra div wrapper or not. Can existing elements be utilised for background images without adding extraneous code?

Thinking ahead and planning your layout beforehand will often lead to more concise code and an easier-to-manage layout.

9. Flexibility

Remember that a web page isn’t the same as a printed page and that ultimately the user has more control over how your page will appear than you do. With this in mind try to allow for some flexibility in your design so that things like text resizing issues don’t break your layout. Don’t make everything a fixed height/width or at least use ems to allow the layout to expand when text is resized.

With a little thought and patience you can still make your page look good and satisfy accessibility requirements.

10. Browser support

A designer’s lot is often not a happy one due to the variance in the display offered via various browsers. There is no easy answer to this question (apart from the tips already given) and my method of working is as follows.

First of all decide with your client (or yourself) what browsers you are aiming to support. This will of course be based on many factors (which we won’t go into here) but could be as simple as checking your server stats to see who your visitors are.

Once you have decided what browsers to support then make sure that you have access to these browsers in some way. The easiest way is to download the browser you need so you can test locally.

If you can’t download the browsers for one reason or another or you need to test on another platform, then there are a number of sites that will offer remote access or screenshots. Some of these require payment and some of the simpler ones are free (a quick look on Google will soon sort you out).

Once you have decided what browsers to support it is time to start coding then you must check your design at every stage in the browsers that you want to support. This means writing a line of code then firing up at least 3 or 4 browsers to check. As you get more experienced you will soon learn what is likely to work and what doesn’t and you can check less frequently.

If you take this approach of checking at every stage then you will soon find out what works and what doesn’t and identify problems straight away and determine the cause is immediately. This would not be the case if you waited until you had finished and then checked the design. It could take hours (or days) to identify where the problem is and what is causing it. It may in fact be too late to fix it because you have built the whole page on a function that only works in one browser and you would have to start again from scratch.

By checking as you go you eliminate this problem and quite often a small change in design at each stage will accommodate nearly all the browsers you need to support without needing to hack. You can’t make these small tweaks and changes in design if you wait until the end.

The above tips for css coding aren’t in any special order and most are just plain common sense. If you follow the advice given you will make your web design life a lot easier and less stressful.

Tip 1: Just don’t settle.  Especially with employees, it is very important to find great people you are compatible with.

Tip 2: There is a benefit from being real experts.  Experience pays off.

Tip 3: Have a healthy disregard for the impossible.  Stretch your goals.

Tip 4: It is OK to solve a hard problem. Solving hard problems is where you will get the biggest leverage.

Tip 5: Don’t pay attention to the VC bandwagon. Don’t start a company just because you can.  Instead, have a really good idea that is good regardless of the funding situation.

*****

One of the things I always tell startups is a principle I learned from Paul Buchheit: it’s better to make a few people really happy than to make a lot of people semi-happy. I was saying recently to a reporter that if I could only tell startups 10 things, this would be one of them. Then I thought: what would the other 9 be?

When I made the list there turned out to be 13:

1. Pick good cofounders.

Cofounders are for a startup what location is for real estate. You can change anything about a house except where it is. In a startup you can change your idea easily, but changing your cofounders is hard. [1] And the success of a startup is almost always a function of its founders.

2. Launch fast.

The reason to launch fast is not so much that it’s critical to get your product to market early, but that you haven’t really started working on it till you’ve launched. Launching teaches you what you should have been building. Till you know that you’re wasting your time. So the main value of whatever you launch with is as a pretext for engaging users.

3. Let your idea evolve.

This is the second half of launching fast. Launch fast and iterate. It’s a big mistake to treat a startup as if it were merely a matter of implementing some brilliant initial idea. As in an essay, most of the ideas appear in the implementing.

4. Understand your users.

You can envision the wealth created by a startup as a rectangle, where one side is the number of users and the other is how much you improve their lives. [2] The second dimension is the one you have most control over. And indeed, the growth in the first will be driven by how well you do in the second. As in science, the hard part is not answering questions but asking them: the hard part is seeing something new that users lack. The better you understand them the better the odds of doing that. That’s why so many successful startups make something the founders needed.

5. Better to make a few users love you than a lot ambivalent.

Ideally you want to make large numbers of users love you, but you can’t expect to hit that right away. Initially you have to choose between satisfying all the needs of a subset of potential users, or satisfying a subset of the needs of all potential users. Take the first. It’s easier to expand userwise than satisfactionwise. And perhaps more importantly, it’s harder to lie to yourself. If you think you’re 85% of the way to a great product, how do you know it’s not 70%? Or 10%? Whereas it’s easy to know how many users you have.

6. Offer surprisingly good customer service.

Customers are used to being maltreated. Most of the companies they deal with are quasi-monopolies that get away with atrocious customer service. Your own ideas about what’s possible have been unconsciously lowered by such experiences. Try making your customer service not merely good, but surprisingly good. Go out of your way to make people happy. They’ll be overwhelmed; you’ll see. In the earliest stages of a startup, it pays to offer customer service on a level that wouldn’t scale, because it’s a way of learning about your users.

7. You make what you measure.

I learned this one from Joe Kraus. [3] Merely measuring something has an uncanny tendency to improve it. If you want to make your user numbers go up, put a big piece of paper on your wall and every day plot the number of users. You’ll be delighted when it goes up and disappointed when it goes down. Pretty soon you’ll start noticing what makes the number go up, and you’ll start to do more of that. Corollary: be careful what you measure.

8. Spend little.

I can’t emphasize how important it is for a startup to be cheap. Most startups fail before they make something people want, and the most common form of failure is running out of money. So being cheap is (almost) interchangeable with iterating rapidly. [4] But it’s more than that. A culture of cheapness keeps companies young in something like the way exercise keeps people young.

9. Get ramen profitable.

“Ramen profitable” means a startup makes just enough to pay the founders’ living expenses. It’s not rapid prototyping for business models (though it can be), but more a way of hacking the investment process. Once you cross over into ramen profitable, it completely changes your relationship with investors. It’s also great for morale.

10. Avoid distractions.

Nothing kills startups like distractions. The worst type are those that pay money: day jobs, consulting, profitable side-projects. The startup may have more long-term potential, but you’ll always interrupt working on it to answer calls from people paying you now. Paradoxically, fundraising is this type of distraction, so try to minimize that too.

11. Don’t get demoralized.

Though the immediate cause of death in a startup tends to be running out of money, the underlying cause is usually lack of focus. Either the company is run by stupid people (which can’t be fixed with advice) or the people are smart but got demoralized. Starting a startup is a huge moral weight. Understand this and make a conscious effort not to be ground down by it, just as you’d be careful to bend at the knees when picking up a heavy box.

12. Don’t give up.

Even if you get demoralized, don’t give up. You can get surprisingly far by just not giving up. This isn’t true in all fields. There are a lot of people who couldn’t become good mathematicians no matter how long they persisted. But startups aren’t like that. Sheer effort is usually enough, so long as you keep morphing your idea.

13. Deals fall through.

One of the most useful skills we learned from Viaweb was not getting our hopes up. We probably had 20 deals of various types fall through. After the first 10 or so we learned to treat deals as background processes that we should ignore till they terminated. It’s very dangerous to morale to start to depend on deals closing, not just because they so often don’t, but because it makes them less likely to.

Having gotten it down to 13 sentences, I asked myself which I’d choose if I could only keep one.

Understand your users. That’s the key. The essential task in a startup is to create wealth; the dimension of wealth you have most control over is how much you improve users’ lives; and the hardest part of that is knowing what to make for them. Once you know what to make, it’s mere effort to make it, and most decent hackers are capable of that.

Understanding your users is part of half the principles in this list. That’s the reason to launch early, to understand your users. Evolving your idea is the embodiment of understanding your users. Understanding your users well will tend to push you toward making something that makes a few people deeply happy. The most important reason for having surprisingly good customer service is that it helps you understand your users. And understanding your users will even ensure your morale, because when everything else is collapsing around you, having just ten users who love you will keep you going.

Notes
[1] Strictly speaking it’s impossible without a time machine.
[2] In practice it’s more like a ragged comb
[3] Joe thinks one of the founders of Hewlett Packard said it first, but he doesn’t remember which.
[4] They’d be interchangeable if markets stood still. Since they don’t, working twice as fast is better than having twice as much time.

- Install apache: http://www.mydigitallife.info/2006/04/13/installing-web-server-in-freebsd-60-with-apache-22-mysql-50-and-php-5-part-4/

- Install php; http://www.mydigitallife.info/2006/04/14/installing-web-server-in-freebsd-60-with-apache-22-mysql-50-and-php-5-part-5/

- Memcache: http://code.google.com/p/memcached/wiki/FAQ#How_can_I_install_memcached?

The error in /var/log/httpd-error.log was as simple as this:

[warn] Session Cache is not configured [hint: SSLSessionCache]

when Php is not installed, Apache worked fine. I had tried to uninstall and reinstall many times but no avail. At last, the savor is :

vi /usr/local/etc/php/extensions.ini
#extension=recode.so (check it marked)
/usr/local/sbin/apachectl start

Why the hell did I compose recode with php-extensions.

Thanks to : http://chris-jan.blogspot.com/2008/08/freebsd-apachesession-cache-is-not.html