Previous Table of Contents Next Oversubscription So you hear the cry "the Internet is slow!" In fact, the users say it's slow the great majority of the time. Although the users in question have a T1 connection to their ISP, they say their browsers are going about as fast as they do when they dial up AOL or CompuServe. Yuck! There were two possibilities: the users are the cause of the slowness or the provider is the cause of the slowness. You choose to measure network utilization at their DMZ to rule out the provider. You also choose an analyzer that provides general network utilization of the segment, and in particular, the throughput to the ISP router. Guess what? The maximum throughput you see going into the ISP router is anywhere from 64Kbps to 80Kbps-very shy of a T1, and not adequate for the number of users on the network. Because you've made sure, from another station, to attempt to shove more packets through the line (which had no effect), it stands to reason that the router or the provider is at fault. There are no errors on the router; the router's resources are fine. What's more, the router is rated to be able to manage a T1's worth of data at one time. So what's happening? The answer: These folks are the victims of oversubscription, an (unfortunately) common occurrence with ISPs. It happens when an ISP "oversells" its pipeline, kind of like when airlines overbook their flights. You can only get so many folks on, and after that they get bumped and delayed. Looking at Figure 23.2, you can see an example of an ISP that has more "lanes" coming in to its site than it has going out. Naturally, there will be traffic jams. [23-02t.jpg] Figure 23.2 An oversubscribed ISP's users are going to experience "traffic jams." Server Out of Gas Let's say you suspect that the server is not as "zippy" as it ought to be. How do you check? Let's look at an example where a user tells you that her application is running ten times slower than it used to. It's starting to affect her life; she's having to come in at night and complete the run before the new day starts. She's mad as heck and isn't going to take it anymore! She tells you, "This network is getting slower and slower every day." You know that the application she's talking about is running on a UNIX host. You know because you made it a point to say, "Would you show me, please?" Otherwise, a communication jam (between you and her) could send you on the wrong track. As soon as you saw her open a Telnet session to a UNIX host and log on, you knew, objectively, that this application lived on a UNIX host. Check with other users of the UNIX host. Are they having problems? Some of them are disgruntled: "Yes, things are pretty slow." Others are not. You examine who is having problems and find that they're mostly people running reports. Because you know that the processing for reports takes place on the UNIX host itself, you naturally suspect the UNIX host as the culprit. If you suspected a network problem at this point, you might time an FTP transfer of a large file to this UNIX host to rule out a network problem. You don't, however, suspect a network problem, because all the folks who are reporting problems are largely doing back-end processing on the UNIX host. You decide to monitor the resources of the UNIX host. You perform a vmstat and come up with this: procs memory page faults cpu -------------------------------------------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 16894 120 1 0 78 208 312 0 279 1208 94 5 19 54 22 0 0 17091 173 1 8 95 288 872 0 271 2730 180 13 34 33 20 4 1 17112 123 0 48 0 168 635 0 293 3751 386 20 51 0 29 6 1 17050 267 0 48 0 152 652 0 267 4124 359 24 44 0 32 Wow! It looks horrible. What in blazes does this cryptic output mean? (Hint: See Hour 8, "Hard Basics: Guide to Being a Hardware Geek," for a verbose description of these column headings.) For the purposes of this discussion, the salient points here are contained in the fre, po, and pi columns. Basically, this output is showing that you have very little memory in the free list and that page-outs (po) and page-ins (pi) are way up. Remember that paging activity takes a really, really long time in comparison to using physical memory. All this paging activity sure does slow things down. To be absolutely sure that this is the problem, you monitor the paging activity during the times the users say the box is slow. There's definitely a correlation. You recommend a memory upgrade, and as soon as the memory is installed, the problem goes away. Excellent! ______________________________________________________________ Certain third-party vendors make graphical long-term server resource reporting tools; if you have long-term problems, it might be worth investing in one of these. The graphical representation of resource use can really be helpful in spotting resource trends that can be dealt with before you have problems. (The Microsoft System Monitor is certainly a good start, but even more sophisticated tools are available.) ______________________________________________________________ Previous Table of Contents Next