thegoodfellas/blogset-br huggingface dataset:
file will be filled with random content using dd.[user@fedora9 ~]$ dd if=/dev/urandom of=500MBfile bs=1M count=500For this, /dev/urandom[2] will supply random numbers, which will be generated by the kernel. This will lead to an increased load on the CPU (sy system time). At the same time, the vmstat executing in parallel will indicate that between 93% and 97% of the CPU time is being used for the execution of kernel code (for the generation of random numbers, in this case).[user@fedora9 ~]$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 402944 54000 161912 745324 5 14 54 59 221 867 13 3 82 2 0 1 0 402944 53232 161916 748396 0 0 0 0 30 213 3 97 0 0 0 1 0 402944 49752 161920 751452 0 0 0 0 28 290 4 96 0 0 0 1 0 402944 45804 161924 755564 0 0 0 0 29 188 2 98 0 0 0 1 0 402944 42568 161936 758608 0 0 0 17456 272 509 7 93 0 0 0[user@fedora9 ~]$The time for executing system calls[3][4][5] will be counted as system time (sy).RAM Bottleneck (swapping) ExampleIn this example, many applications will be opened (including VirtualBox with a Windows guest system, among others). Almost all of the working memory will be used. Then, one more application (OpenOffice) will be started. The Linux kernel will then swap out several memory pages to the swap file on the hard disk, in order to get more RAM for OpenOffice. Swapping the memory pages to the swap file will be seen in the so (swap out - memory swapped to disk) column as vmstat executes in parallel.[user@fedora8 ~]$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 244208 10312 1552 62636 4 23 98 249 44 304 28 3 68 1 0 0 2 244920 6852 1844 67284 0 544 5248 544 236 1655 4 6 0 90 0 1 2 256556 7468 1892 69356 0 3404 6048 3448 290 2604 5 12 0 83 0 0 2 263832 8416 1952 71028 0 3788 2792 3788 140 2926 12 14 0 74 0 0 3 274492 7704 1964 73064 0 4444 2812 5840 295 4201 8 22 0 69 0[user@fedora8 ~]$High IO Read Load ExampleA large file (such as an ISO file) will be read and written to /dev/null using dd.[user@fedora9 ~]$ dd if=bigfile.iso of=/dev/null bs=1MExecuted in parallel, vmstat will show the increased IO read load (the bi value).[user@fedora9 ~]$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 465872 36132 82588 1018364 7 17 70 127 214 838 12 3 82 3 0 0 1 465872 33796 82620 1021820 0 0 34592 0 357 781 6 10 0 84 0 0 1 465872 36100 82656 1019660 0 0 34340 0
358 723 5 9 0 86 0 0 1 465872 35744 82688 1020416 0 0 33312 0 345 892 8 11 0 81 0 0 1 465872 35716 82572 1020948 0 0 34592 0 358 738 7 8 0 85 0[user@fedora9 ~]$ High IO Write Load ExampleIn contrast with the previous example, dd will read from /dev/zero and write a file. The oflag=dsync will cause the data to be written immediately to the disk (and not merely stored in the page cache).[user@fedora9 ~]$ dd if=/dev/zero of=500MBfile bs=1M count=500 oflag=dsyncExecuted in parallel, vmstat will show the increased IO write load (the bo value).[user@fedora9 ~]$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 1 1 0 35628 14700 1239164 0 0 1740 652 117 601 11 4 66 20 0 0 1 0 34852 14896 1239788 0 0 0 23096 300 573 3 16 0 81 0 0 1 0 32780 15080 1241304 0 0 4 21000 344 526 1 13 0 86 0 0 1 0 36512 15244 1237256 0 0 0 19952 276 394 1 12 0 87 0 0 1 0 35688 15412 1237180 0 0 0 18904 285 465 1 13 0 86 0[user@fedora9 ~]$ CPU Waiting for IO ExampleIn the following example, an updatedb process is already running. The updatedb utility is part of mlocate. It examines the entire file system and accordingly creates the database for the locate command (by means of which file searches can be performed very quickly). Because updatedb reads all of the file names from the entire file system, the CPU must wait to get data from the IO system (the hard disk). For that reason, vmstat running in parallel will display large values for wa (waiting for IO):[user@fedora9 ~]$ vmstat 1 5procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 2 1 403256 602848 17836 400356 5 15 50 50 207 861 13 3 83 1 0 1 0 403256 601568 18892 400496 0 0 1048 364 337 1903 5 7 0 88 0 0 1 403256 600816 19640 400568 0 0 748 0 259 1142 6 4 0 90 0 0 1 403256 600300 20116 400800 0 0 476 0 196 630 8 5 0 87 0 0 1 403256 599328 20792 400792 0 0 676 0 278 1401 7 5 0 88 0[user@fedora9 ~]$Additional vmstat Optionsvmstat --help[user@fedora9 ~]$ vmstat --helpusage: vmstat [-V] [-n] [delay [count]] -V prints version. -n causes the headers not to be reprinted regularly. -a print inactive/active page stats. -d prints disk statistics -D prints disk table -p prints disk partition statistics -s prints vm table -m prints slabinfo -S unit size delay is the delay between updates in seconds. unit size k:1000 K:1024 m:1000000 M:1048576 (default is K) count is the number of updates.[user@fedora9 ~]$vmstat[user@fedora9 ~]$ vmstatprocs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy
id wa st 2 0 14960 38016 6584 1069284 0 1 506 81 727 1373 12 4 81 3 0[user@fedora9 ~]$vmstat -V[user@fedora9 ~]$ vmstat -Vprocps version 3.2.7[user@fedora9 ~]$vmstat -a[user@fedora9 ~]$ vmstat -aprocs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free inact active si so bi bo in cs us sy id wa st 3 0 14960 38024 988284 461704 0 1 506 81 726 1372 12 4 81 3 0[user@fedora9 ~]$vmstat -d[user@fedora9 ~]$ vmstat -ddisk- ------------reads------------ ------------writes----------- -----IO------ total merged sectors ms total merged sectors ms cur secram0 0 0 0 0 0 0 0 0 0 0ram1 0 0 0 0 0 0 0 0 0 0ram2 0 0 0 0 0 0 0 0 0 0ram3 0 0 0 0 0 0 0 0 0 0ram4 0 0 0 0 0 0 0 0 0 0ram5 0 0 0 0 0 0 0 0 0 0ram6 0 0 0 0 0 0 0 0 0 0ram7 0 0 0 0 0 0 0 0 0 0ram8 0 0 0 0 0 0 0 0 0 0ram9 0 0 0 0 0 0 0 0 0 0ram10 0 0 0 0 0 0 0 0 0 0ram11 0 0 0 0 0 0 0 0 0 0ram12 0 0 0 0 0 0 0 0 0 0ram13 0 0 0 0 0 0 0 0 0 0ram14 0 0 0 0 0 0 0 0 0 0ram15 0 0 0 0 0 0 0 0 0 0sda 136909 31536 13893867 1197609 58190 219323 2233264 7688807 0 677sda1 35703 6048 1326394 511477 6728 16136 182984 419232 0 222sda2 85 1489 2935 653 141 3603 29952 5254 0 1sda3 101111 23961 12564154 685330 51321 199584 2020328 7264321 0 512sr0 0 0 0 0 0 0 0 0 0 0fd0 0 0 0 0 0 0 0 0 0 0[user@fedora9 ~]vmstat -D[user@fedora9 ~]$ vmstat -D 22 disks 0 partitions 273820 total reads 63034 merged reads 27787446 read sectors 2395193 milli reading 116450 writes 438666 merged writes 4467248 written sectors 15377932 milli writing 0 inprogress IO 1412 milli spent IOvmstat -pvmstat -p will not work under Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=485246. The following report comes from an Ubuntu 9.10 system.user@ubuntu-9-10:~$ vmstat -p /dev/sda9sda9 reads read sectors writes requested writes 23420 411365 24464 530801user@ubuntu-9-10:~$vmstat -s[user@fedora9 ~]$ vmstat -s 1553972 total memory 1516180 used memory 461892 active memory 988304 inactive memory 37792 free memory 6644 buffer memory 1069388 swap cache 1052248 total swap 14960 used swap 1037288 free swap 161467 non-nice user cpu ticks 7586 nice user cpu ticks 46310 system cpu ticks 1108919 idle cpu ticks 46832 IO-wait cpu ticks 2694 IRQ cpu ticks 2452 softirq cpu ticks 0 stolen cpu ticks 6947021 pages paged in 1116896 pages paged out 183 pages swapped in 3744 pages swapped out 9985406 interrupts 18852586 CPU context switches 1239004323 boot time 15072 forks[user@fedora9 ~]$vmstat -m[user@fedora9 ~]$ vmstat -mCache Num Total Size Pagesfuse_request 11 11 368 11fuse_inode 9 9 448 9rpc_inode_cache 8 8 512 8nf_conntrack_expect 0 0 168 24nf_conntrack 26 80 248 16dm_uevent 0 0 2464 3UDPv6 22 22 704 11TCPv6 6 6
1344 6kmalloc_dma-512 8 8 512 8sgpool-128 12 12 2048 4scsi_io_context 0 0 104 39ext3_inode_cache 6822 8360 496 8ext3_xattr 85 85 48 85journal_handle 170 170 24 170journal_head 76 219 56 73revoke_record 256 256 16 256flow_cache 0 0 80 51bsg_cmd 0 0 288 14mqueue_inode_cache 7 7 576 7isofs_inode_cache 0 0 376 10hugetlbfs_inode_cache 11 11 344 11dquot 0 0 128 32shmem_inode_cache 1058 1071 448 9xfrm_dst_cache 0 0 320 12UDP 19 21 576 7TCP 17 24 1216 6blkdev_queue 21 21 1080 7biovec-256 2 2 3072 2biovec-128 5 5 1536 5biovec-64 7 10 768 5sock_inode_cache 619 650 384 10file_lock_cache 39 39 104 39Acpi-Operand 2935 2958 40 102Acpi-Namespace 1700 1700 24 170Cache Num Total Size Pagestaskstats 25 26 312 13proc_inode_cache 233 242 360 11sigqueue 28 28 144 28radix_tree_node 7888 8606 296 13bdev_cache 24 24 512 8inode_cache 370 462 344 11dentry 6592 15390 136 30names_cache 2 2 4096 2avc_node 73 73 56 73selinux_inode_security 9888 10030 48 85idr_layer_cache 627 644 144 28buffer_head 2308 2688 64 64mm_struct 659 693 448 9vm_area_struct 11110 11592 88 46files_cache 115 130 384 10sighand_cache 141 150 1344 6task_struct 246 248 3696 2anon_vma 4778 5120 16 256kmalloc-4096 95 112 4096 8kmalloc-2048 272 304 2048 16kmalloc-1024 518 524 1024 4kmalloc-512 764 888 512 8kmalloc-256 198 208 256 16kmalloc-128 629 832 128 32kmalloc-64 4322 5568 64 64kmalloc-32 1554 1664 32 128kmalloc-16 2644 3584 16 256kmalloc-8 3561 3584 8 512kmalloc-192 6349 6930 192 21kmalloc-96 885 1176 96 42[user@fedora9 ~]$ Referenceshttp://lame.sourceforge.net/http://en.wikipedia.org/wiki//dev/randomhttp://en.wikipedia.org/wiki/System_callhttp://www.softpanorama.org/Internals/unix_system_calls.shtmlhttp://www.ibm.com/developerworks/linux/library/l-system-calls/
the current script.$nThese variables correspond to the arguments with which a script was invoked. Here n is a positive decimal number corresponding to the position of an argument (the first argument is $1, the second argument is $2, and so on).$#The number of arguments supplied to a script.$*All the arguments are double quoted. If a script receives two arguments, $* is equivalent to $1 $2.$@All the arguments are individually double quoted. If a script receives two arguments, $@ is equivalent to $1 $2.$?The exit status of the last command executed.$$The process number of the current shell. For shell scripts, this is the process ID under which they are executing.$!The process number of the last background command.Command-Line Arguments:The command-line arguments $1, $2, $3,...$9 are positional parameters, with $0 pointing to the actual command, program, shell script, or function and $1, $2, $3, ...$9 as the arguments to the command.Following script uses various special variables related to command line:#!/bin/shecho "File Name: $0"echo "First Parameter : $1"echo "First Parameter : $2"echo "Quoted Values: $@"echo "Quoted Values: $*"echo "Total Number of Parameters : $#"Here is a sample run for the above script:$./test.sh Zara AliFile Name : ./test.shFirst Parameter : ZaraSecond Parameter : AliQuoted Values: Zara AliQuoted Values: Zara AliTotal Number of Parameters : 2Special Parameters $* and $@:There are special parameters that allow accessing all of the command-line arguments at once. $* and $@ both will act the same unless they are enclosed in double quotes, "".Both the parameter specifies all command-line arguments but the "$*" special parameter takes the entire list as one argument with spaces between and the "$@" special parameter takes the entire list and separates it into separate arguments.We can write the shell script shown below to process an unknown number of command-line arguments with either the $* or $@ special parameters:#!/bin/shfor TOKEN in $*do echo $TOKENdoneThere is one sample run for the above script:$./test.sh Zara Ali 10 Years OldZaraAli10YearsOldNote: Here do...done is a kind of loop which we would cover in subsequent tutorial.Exit Status:The $? variable represents the exit status of the previous command.Exit status is a numerical value returned by every command upon its completion. As a rule, most commands return an exit status of 0 if they were successful, and 1 if they were unsuccessful.Some commands return additional exit statuses for particular reasons. For example, some commands differentiate between kinds of errors and will return various exit values depending on the specific type of failure.Following is the example of successful command:$./test.sh Zara AliFile Name : ./test.shFirst Parameter : ZaraSecond Parameter : AliQuoted Values: Zara AliQuoted Values: Zara AliTotal Number of Parameters : 2$echo $?0$Fonte: tutorialspoint
Today I ran into a problem with IPsec Xauth PSK and the built-in Android VPN client (Android 4.1.2), resulting in some sites (such as www.yahoo.com) not loading through the VPN tunnel. Turns out I was dealing with MTU issues. When the Android VPN is started, it sets the MTU to 1500 on the tun0 interface:$ ip link show tun033: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500 link/noneLooking at the Android Source, it appears someone must have forgotten to take care of IPsec Xauth PSK. With PPTP and L2TP based VPNs, the MTU is reduced to 1400 (line 758 778).In comparison:strongSwan Android client: MTU 1400OS X / iOS 7 built-in IPsec client: MTU 1280 (for what its worth, 1280 is also the minimum IPv6 packet size and thus the MTU minimum required to make IPv6 work)Windows 7 built-in IPsec client: MTU 1400Cisco VPN client: MTU 1300Among the tested clients, only the connection through the Android VPN client was causing the issue with stalling websites. In a nutshell, I was able to fix it with the following on the VPN server:$ iptables -t mangle -A FORWARD -o eth0 \ -p tcp -m tcp --tcp-flags SYN,RST SYN \ -m tcpmss --mss 1361:1536 \ -j TCPMSS --set-mss 1360$ echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_discAnd here is why.IP fragmentation The original problem.On the VPN server side, we have the interface set to a standard Ethernet MTU 1500. In the scenario with the Android client, the MTU along the entire path is 1500. This leaves room for up to 1460 bytes of data payload per packet (also referred to as the maximum segment size MSS).Keep in mind that IPsec in tunnel mode adds an ESP header and an additional IP header for tunneling the packet (usually with an additional size of around 70-80 bytes). When a packet is nearly the size of the MTU and when you tack on this encapsulation overhead, it is likely to exceed the MTU of the outbound link. Thats where IP fragmentation kicks in which could lead to performance degradation of your VPN tunnel. Or worse...Path MTU discovery (PMTUD). A failed solution.To avoid IP fragmentation, many TCP/IP stacks have path MTU discovery (PMTUD) implemented. To tell you right away: It doesnt work for me, and its not going to work for you either. PMTUD attempts to discover the largest IP datagram that may be sent without fragmentation through an IP path. Instead of fragmenting a too-large IP packet, the VPN server is told (through theDont Fragment (DF) flag in the IP header of the sender) to discard the packet and reply with an ICMP fragmentation required (type3, subtype 4) message.Recap: The sender is the website that you try to load on your VPN client.When the sender receives this ICMP packet, it learns to use a smaller MTU for packets sent to our VPN server. In theory. In reality, many websites (senders like www.yahoo.com) stupidly implement ICMP filters that break PMTUD functionality. And thats where hell breaks loose. The sender is expecting an acknowledgement for the original packet from our server, but since the
packet was discarded, the acknowledgment never comes. Time goes by, then the sender repeats sending the too-large packet. The result? The VPN sender discards the packet, again, sends yet another ICMP message, and so on. Meanwhile our client on the other end of the VPN tunnel cannot tell whats happening and is desperately waiting for some data. Everything appears to be stalled a state which is also referred to as a black hole connection.Because PMTUD doesnt always work on the Internet, the use of it only makes sense in a site-to-site VPN, where basically one operator maintains the networks and is able to enable the forwarding of the fragmentation required ICMP (type 3, subtype 4) notifications in all firewalls in between.MSS size reduction. A working solution.So we can rule out PMTUD, but there is another way to assure that our VPN connection is working properly.$ iptables -t mangle -A FORWARD -o eth0 \ -p tcp -m tcp --tcp-flags SYN,RST SYN \ -m tcpmss --mss 1361:1536 \ -j TCPMSS --set-mss 1360This iptables rule reduces the size of the allowed packet size by reducing the MSS of TCP SYN packets. The set-mss value explicitly sets the MSS to 1360, which is a customary size for IPsec IPv4 interfaces. The mss option is used to match only those MSS that are between 1361 and 1536 bytes (we dont want to rewrite the MSS of a VPN client that uses a smaller MSS). The result in a tcpdump:05:01:56.795798 IP 172.16.16.1.38695 > r2.ycpi.vip.ac4.yahoo.net.http: Flags [S], seq 2621580326, win 14600, options [mss 1460,sackOK,TS val 56614 ecr 0,nop,wscale 6], length 005:01:56.795865 IP vpn.zeitgeist.se.38695 > r2.ycpi.vip.ac4.yahoo.net.http: Flags [S], seq 2621580326, win 14600, options [mss 1360,sackOK,TS val 56614 ecr 0,nop,wscale 6], length 005:01:56.802695 IP r2.ycpi.vip.ac4.yahoo.net.http > vpn.zeitgeit.se.38695: Flags [S.], seq 3057551576, ack 2621580327, win 14480, options [mss 1460,sackOK,TS val 1410945796 ecr 56614,nop,wscale 8], length 0In line 1, you see the request from our Android client through the tunnel to yahoo.com. Notice the MSS is 1460. In the second line, it is our VPN host initiating the TCP handshake with the external site. Only now the MSS value is rewritten to 1360, thanks to our iptables rule. As a consequence, the TCP connection will use the lower MSS of the two end points, which is 1360. Voila!You can go further and restrict the iptables rule to rewrite only those packets that are forwarded from our VPN client:$ iptables -t mangle -A FORWARD -o eth0 \ -p tcp -m tcp --tcp-flags SYN,RST SYN \ -s 172.16.16.0/24 \ -m tcpmss --mss 1361:1536 \ -j TCPMSS --set-mss 1360This assumes that the address pool of your virtual IPs is 172.16.16.0/24 (see rightsourceip in /etc/ipsec.conf).There is also an option to determine the MSS size dynamically (MSS clamping, via the clamp-mss-to-pmtu option), but it wouldnt fix IPsec for clients that set their MTU too high (like in the Android example).The MSS iptables rule doesnt work with UDP applications. UDP is a connectionless protocol; hence there is no way to negotiate a MSS during the handshake. The only solution to guarantee that UDP works is to disable the Dont
Fragment (DF) bit in the IP header of the sender. This will allow our VPN server to fragment any UDP packet, if necessary. In Linux, you do it like this:$ echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_discThe VPN server will fragment outgoing UDP packets that exceed the interface MTU, which may not be as great for performance and reliability reasons, but at least it doesnt break the tunnel connection. Fortunately, most folks dont use UDP for anything much greater than DNS.Fonte: zeitgeist.se
As of Debian 5.04 (Lenny), Debian doesnt support mounting ext4 partitions out of the box, or rather, we should say, using conventional methods.Trying to mount an ext4 partition using the mount directive yields the error :?1mount: unknown filesystem type 'ext4'The roundabout way of doing it is setting a test_fs flag on the partition using the tune2fs utility.?123su -tune2fs -E test_fs /dev/hda1mount -t ext4dev /dev/hda1 /place/to/mount/Replace hda1 with the name of the ext4 partition you want to mount.No related posts.Source: http://techtitbits.com/2010/05/mounting-ext4-partitions-on-debian/ Comando TOP# topO comando top no Linux exibe os processos em execucao no sistema. Uma das ferramentas mais importantes para um administrador do sistema. E amplamente utilizado para monitorar a carga do sistema. Nesse artigo e explorado o comando top em detalhes, pois ele e um comando interativo; ou seja, muitos outros comandos estao disponiveis quando ele esta executando. Sendo assim, domine o comando top!I SAIDA DO COMANDO TOPtoptop - 23:18:09 up 1:45, 1 user, load average: 0.76, 0.78, 0.76Tasks: 192 total, 1 running, 190 sleeping, 0 stopped, 1 zombieCpu(s): 15.4%us, 5.7%sy, 0.0%ni, 78.8%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%stMem: 3058052k total, 2100524k used, 957528k free, 168696k buffersSwap: 3481788k total, 0k used, 3481788k free, 1099720k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3187 ricardo 20 0 1129m 403m 43m S 14 13.5 28:23.04 firefox 1238 root 20 0 98840 27m 8876 S 6 0.9 4:45.38 Xorg 2398 ricardo 20 0 429m 76m 29m S 4 2.6 3:01.05 compiz 3352 ricardo 20 0 246m 53m 22m S 2 1.8 2:20.39 plugin-containe 2431 ricardo 20 0 196m 25m 15m S 2 0.9 0:03.11 python 2552 ricardo 20 0 166m 11m 8456 S 1 0.4 0:04.21 bamfdaemon 2955 root 20 0 0 0 0 S 1 0.0 0:04.06 kworker/0:3 2370 ricardo 20 0 6836 3352 632 S 1 0.1 0:14.33 dbus-daemonPrimeiramente, e preciso entender a saida do comando (mostrada acima). Ela exibe uma serie de informacoes sobre o sistema em funcionamento. Entao, e preciso ficar ciente das secoes mostradas:1 Tempo de atividade e media de carga do sistema (Uptime and Load Averages)top - 23:18:09 up 1:45, 1 user, load average: 0.76, 0.78, 0.76Na parte superior do comando top e apresentada a saida similar ao comando uptime.* O tempo atual * O tempo que seu sistema esta funcionando * Numero de usuarios autenticados no sistema no momento * Media de carga de 5, 10 e 15 minutos respectivamente.2 Tarefas (Tasks)Tasks: 192 total, 1 running, 190 sleeping, 0 stopped, 1 zombieA segunda linha mostra resumo das tarefas ou processos. Os processos podem ser em diferentes estados. Ela mostra o numero total de processos. Destes, os processos podem estar executando (running), dormindo (sleeping), parado (stopped) ou modo zumbi (zombie)3 Estados da CPU (CPU States)Cpu(s): 15.4%us, 5.7%sy, 0.0%ni, 78.8%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%stEm seguida e apresentado o estado da CPU. O significado dos diferentes tempos de CPU sao:* us, usuario (user): tempo de CPU na execucao dos processos de usuario * Sy, sistema (sytem): tempo de CPU na execucao de processos do kernel * Id, ocioso (idle): tempo de CPU em inatividade * Wa, tempo