Actually there must be a problem.... I don't know the details of ubuntu server, but on Debian you'd turn off the GUI with the command
/etc/init.d/gdm stop
Then about the loaded CPU : either it's some mad process gone awry (possibly in the graphical environment), or a crashed kernel driver. First, use the top command to identify which process consumes that CPU power, here's an example of 'top' output with a process ('dnetc') fully loading the CPU:
top - 18:11:54 up 157 days, 7:47, 3 users, load average: 1.07, 1.25, 1.25
Tasks: 122 total, 2 running, 120 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.7%us, 1.0%sy, 94.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 1034424k total, 971320k used, 63104k free, 61636k buffers
Swap: 8000352k total, 116816k used, 7883536k free, 202912k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5059 emmanuel 39 19 7780 4364 184 R 94.4 0.4 6919:54 dnetc
16077 root 20 0 117m 53m 6728 S 2.7 5.3 10:45.67 X
17783 emmanuel 20 0 990m 487m 30m S 2.3 48.3 20:11.99 firefox
17606 emmanuel 20 0 9340 5368 3248 S 0.7 0.5 0:02.82 wmaker
Another indication in 'top' output is the "Cpu" line: it shows if it's a user, system, nice or waiting process that gobbles up your system resources. If no definite process consumes your CPU, it may be some blocked IO (wait), for instance because of a faulty drive, or a crashed driver (often because of some faulty hardware). See the output from the 'dmesg' command or the '/var/log/messages' file to identify kernel driver crashes or Oopses or crashes :
CPU 3:
Modules linked in: pvfs2 bonding md_mod ipv6 fan ac battery dm_snapshot dm_mirror dm_mod af_packet sg loop usbhid uhci_hc
d usb_storage e1000 8250_pnp 8250 serial_core rtc shpchp pcspkr k8temp i2c_nforce2 button pci_hotplug thermal processor i2c_core ehci_hcd forcedeth ohci_hcd u
sbcore evdev 3w_9xxx sata_nv libata
Pid: 12124, comm: pvfs2-client-co Tainted: G D 2.6.24.7-storiq64-opteron #1
RIP: 0010:[<ffffffff80502ad7>] [<ffffffff80502ad7>] _spin_lock+0x7/0x10
RSP: 0018:ffff8102a48e3ec0 EFLAGS: 00000286
RAX: 00000000fffffe53 RBX: 00000000fffffe53 RCX: ffff8102a48e3f50
RDX: 00000000fffffe53 RSI: 00000000000001fd RDI: ffff81041692d7e0
RBP: ffff81000104b600 R08: ffff810414c8d928 R09: ffff810414c8d900
R10: 0000000000000000 R11: 0000000000000202 R12: ffff81000104fa20
R13: 0000000000000000 R14: ffff810236df1018 R15: ffff810417662b80
FS: 00002b365c208ae0(0000) GS:ffff81041811f640(0000) knlGS:00000000f7ddf8e0
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000628288 CR3: 000000029b6ef000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
[<ffffffff881e481f>] :pvfs2:pvfs2_devreq_read+0x1cf/0x400
[<ffffffff802954f5>] vfs_read+0xc5/0x160
[<ffffffff802959d3>] sys_read+0x53/0x90
[<ffffffff8020bc1e>] system_call+0x7e/0x83
Another possibility is an IO error on a dying drive, something like :
Apr 30 04:05:26 linux kernel: end_request: I/O error, dev /dev/sda sector 53445
Now how to correct the problem? If it's some user program gone crazy, simply kill it. First try to kill it politely with kill <process ID> or killall <program name>, for instance to kill the 'dnetc' program from the previously seen 'top' output, either would do:
kill 5059
killall dnetc
But there is some chance that it simply won't respond because it's broken up beyond any repair. So you'll have to force kill it with kill -9 <pid> or killall -9 <program name>
kill -9 5059
killall -9 dnetc
What about faulty drivers or kernel? Unfortunately only a reboot can fix it. As for the faulty drive, well, you'll have to replace it, there's no way around.
topshould show you what's using CPU.iostatcan show you disk usage, etc. There are plenty of basic troubleshooting techniques outlined on this site and on many others. – MDMarra Nov 17 '11 at 17:20