PHP Manual
PEAR Manual
Smarty Manual
PostgreSQL
MySQL Manual
Perl Manual
Ciekawe adresy
Czytnik RSS
» TDK: Optyczne dyski 320GBTDK ogłosiło opracowanie prototypu optycznego dysku mieszczącego 320GB informacji, czyli 6 razy więcej od obecnie dostępnych nośników o najwyższej pojemności. Dwunastocentymetrowy dysk ma 10 warstw zapisu, każda z nich ma przechowywać 32GB. Dyski Blu-ray potrafią zapisać do 25GB na każdą warstwę, a największymi nośnikami dostępnymi na rynku są ich wersje dwuwarstwowe.
» Bankier.pl schodzi z giełdy
Walne Zgromadzenie spółki Bankier.pl zdecydowało o wycofaniu akcji firmy z obrotu na rynku regulowanym Giełdy Papierów Wartościowych.
» AMD wypuszcza nowe roadmapy, platformia Scorpius w 2011
W Internecie pojawiły się nowe roadmapy AMD. Nową platformą będzie Leo, bazowaną na zgodnymi z przewidywaniami procesorami na jądrze Thuban, które będą sześciordzeniową wersją obecnych procesorów serii Phenom II X4. Procesory będą oparte o serwerowe odpowiedniki o nazwie kodowej Istanbul. Razem z Thubanami pojawi się chipset RD890, przewidziany jako AMD 890FX oraz mostek południowy SB850. Grafika będzie oparta o serię ATI HD 5000 DX11.
» Battlestar Galactica Online - nowa gra MMO w produkcji
Firma Bigpoint poinformowała, że planuje wydać grę sieciową MMORPG opartą na serialu telewizyjnym z gatunku science-fiction - Battlestar Galactica.
chapter 24. monitoring database activity
- table of contents
- 24.1. standard unix tools
- 24.2. the statistics collector
- 24.2.1. statistics collection configuration
- 24.2.2. viewing collected statistics
- 24.3. viewing locks
a database administrator frequently wonders, "what is the system doing right now?" this chapter discusses how to find that out.
several tools are available for monitoring database activity and analyzing performance. most of this chapter is devoted to describing postgresql's statistics collector, but one should not neglect regular unix monitoring programs such as ps, top, iostat, and vmstat. also, once one has identified a poorly-performing query, further investigation may be needed using postgresql's explain command. section 13.1 discusses explain and other methods for understanding the behavior of an individual query.
24.1. standard unix tools
on most platforms, postgresql modifies its command title as reported by ps, so that individual server processes can readily be identified. a sample display is
$ ps auxww | grep ^postgres postgres 960 0.0 1.1 6104 1480 pts/1 sn 13:17 0:00 postmaster -i postgres 963 0.0 1.1 7084 1472 pts/1 sn 13:17 0:00 postgres: stats buffer process postgres 965 0.0 1.1 6152 1512 pts/1 sn 13:17 0:00 postgres: stats collector process postgres 998 0.0 2.3 6532 2992 pts/1 sn 13:18 0:00 postgres: tgl runbug 127.0.0.1 idle postgres 1003 0.0 2.4 6532 3128 pts/1 sn 13:19 0:00 postgres: tgl regression [local] select waiting postgres 1016 0.1 2.4 6532 3080 pts/1 sn 13:19 0:00 postgres: tgl regression [local] idle in transaction
(the appropriate invocation of ps varies across different platforms, as do the details of what is shown. this example is from a recent linux system.) the first process listed here is the postmaster, the master server process. the command arguments shown for it are the same ones given when it was launched. the next two processes implement the statistics collector, which will be described in detail in the next section. (these will not be present if you have set the system not to start the statistics collector.) each of the remaining processes is a server process handling one client connection. each such process sets its command line display in the form
postgres: user database host activity
the user, database, and connection source host items remain the same for the life of the client connection, but the activity indicator changes. the activity may be idle (i.e., waiting for a client command), idle in transaction (waiting for client inside a begin block), or a command type name such as select. also, waiting is attached if the server process is presently waiting on a lock held by another server process. in the above example we can infer that process 1003 is waiting for process 1016 to complete its transaction and thereby release some lock or other.
tip: solaris requires special handling. you must use /usr/ucb/ps, rather than /bin/ps. you also must use two w flags, not just one. in addition, your original invocation of the postmaster command must have a shorter ps status display than that provided by each server process. if you fail to do all three things, the ps output for each server process will be the original postmaster command line.
Najskuteczniejsza reklama to pozycjonowanie - Pozycjonowanie stron <= zajrzyj tu i dowiedz się więcej o pozycjonowanie stron