The idlepc value is very important to dynamips and it is both image and often CPU dependent. There is no "magic"value that will work for all images and all CPUs so this is why I'll show you a quick and handy way.
Also don't be disappointed, some values do not work well but idlepc gives you several. For example in my example below #6 didn't help at all but #7 got me down to about 6% CPU from 99-100%.
1.) Make sure your dynagen config file has........
1.) Install dynagen and dynamips
2.)Also configure your bridge or br0
If you don't have a br0 on your Linux machine then follow this guide or video for Debian:
Alternatively you can use NIO_linux_eth:eth0 for f0/0 below but remember the host machine cannot talk to the router then.
Is a mdadm check on your trusty software RAID array happening at the worst time and slowing down your server or NAS?
Personalities : [raid1] [raid10]
md127 : active raid10 sdb4 sda4
897500672 blocks super 1.2 2 near-copies [2/2] [UU]
[==========>..........] check = 50.4% (452485504/897500672) finish=15500.3min speed=478K/sec
Occasionally my whole screen locks up and I cannot even swith to the console and I find this in my syslog:
description: VGA compatible controller
product: Mullins [Radeon R3 Graphics]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
Getting started, let's enable ephones and DNs we can add a phone with a telephone number:
!this enables ephone registration otherwise phones cannot register
!max-ephones 2 says we can have a maximum of 2 phones, change to your needs (or to the limit set by your IOS image)
It looks like this has something to do with APIC but I am not sure. I have similar CPUs with a different MB and BIOS that work fine on the same type of kernel. A lot of time the issue is because of the C-step setting in the BIOS.
The same thing happened on the 2.6 kernel with Centos 6 but this is a homebrew 4.4 kernel soI am not sure why it is happening when even Centos 7 (3.2) kernel works OK.
Solution - It comes down to the BIOS set........
It's fairly simple to start or stop a check but I do wish mdadm's command had this built in. Sometimes it will do a check at the worst time causing the server to crawl to a halt.
Stop check on md126:
echo idle > /sys/block/md126/md/sync_action
Start check on md126:
echo check > /sys/block/md126/md/sync_action
Here's a proven example of what a bad hard drive can do, it was technically functioning OKin a RAID array but the system became extremely low and the load become high and IOWAIT was even higher and I always thought it was a bad application. The truth is that this failing 1TBHitachi has slowly gotten worse and caused huge slowdowns, (eg. 100% load on Thunderbird waiting for e-mails to load etc..). After swapping it out, tabs change instantly, emails are not lagged, and........
mod_status is a great way to track down the source of high CPU usage and to find what vhost/script is the cause of it.
It gives you a live view of bandwith usage, CPU usage, and memory usage broken down by domain/vhost and script/URI.
Deny from all
This happened during a RAID array check:
SMART says both drives pass the test, but I'm doing a long test on them and hopefully this is not a hardware error.
Apr 3 04:22:01 remote kernel: md: syncing RAID array md2
Apr 3 04:22:01 remote kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Apr 3 04:22:01 remote kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
high IO wait
424 root 39 19 1900 848 552 D 0.0 0.0 0:00.91 updatedb
root 424 0.0 0.0 1900 848 ? DN Mar11 0:00 /usr/bin/updatedb -f sysfs?rootfs?bdev?proc?cpuset?binfmt_misc?debugfs?sockfs?usbfs?pipefs?anon_inodefs?futexfs?tmpfs?inotifyfs?eventp........
I think this will be useful to others because I have a server that kept crashing mysteriously during intense disk usage/RAID checks. It would only crash during the weekly RAID integrity check.
ThenI noticed during a reboot that not all CPUs were being brought up, as a result this actually creates much higher temperatures with the output I got from sensors, just booting the system produced higher than normal temperatures.
You can imagine that a full blown RAID check........
Jan 16 04:02:03 centosbox syslogd 1.4.1: restart.
Jan 16 04:07:34 centosbox kernel: INFO: task updatedb:20771 blocked for more than 300 seconds.
Jan 16 04:07:34 centosbox kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 16 04:07:34 centosbox kernel: updatedb D F78BE050 6476 20771 20766&n........
This made me nervous but it's clearly a cronjob based on the messages log that happens every Sunday at about 4:22.
I actually can't find any evidence of it in cron.d cron.daily but it is there somewhere obviously.
What I don't get is why doesn't this cronjob do a datacheck like Ubuntu's cronscript does? When you unnecessarily rebuild the array you lose your redundancy during that point which makes your data extremely vulnerable.
*Update I did a grep of &q........
This doesn't seem to be widely known (maybe it's in some documentation that none of us read though)but there's an easy way to check the integrity of any mdadm array:
sudo echo check > /sys/block/md0/md/sync_action
-bash: /sys/block/md0/md/sync_action: Permission denied
sudo will never work, this only works as root since echo is not actually a binary/command. It is built-into bash.
This really made me nervous but notice the mdstat says "check". This is because in Ubuntu there is a scheduled mdadm cronscript that runs everyday on Sunday at 00:57 that checks your entire array. This is a good way because it prevents gradual but unnoticed data corruption which Inever thought of.
As long as the check completes properly you have peace of mind knowing that your data integretiy is assured and that your hard drives are functioning properly (I'........
This is obviously a bug in the r8169 kernel module and it seems to affect a lot of people. I upgraded to the latest kernel and hope this won't happen anymore, as it is a very serious error. This is especially serious for those who are running servers with this chipset, who can afford for the NIC to randomly go off-line for no apparent reason?
[655548.189113] type=1505 audit(1277067560.902:5): operation="profile_load" name="/usr/bin/freshclam&q........
This drive is clearly on the way out, the Kernel knows it but I'm surprised that SMART is not concerned. I didn't blame Seagate for their past issues until now. This hard drive has hardly been used and has not even been powered on for a year according to SMART.
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.11
The binary "iostat" comes from the package "sysstat" and is available on all Linux/Unix like platforms.
Use the "-m" option to give you what you probably want, which is to see in MB/s how much bandwidth each disk is doing.
Linux 220.127.116.11 ((none)) 04/16/10
avg-cpu: %user %nice %system %iowait %steal %idle
heartbeat is stopped for some reason
Anyway hnode2 was active and the services are running fine but I see heartbeat has been stopped somehow.
Here is the last log I see of heartbeat:
Sep 9 17:15:32 hnode2 heartbeat: : info: MSG stats: 9/1762471 ms age 0 [pid16738/MST_CONTROL]
Sep 9 17:15:32 hnode2 heartbeat: : info: cl_malloc stats: 716/51784021 152624/74519 [pid16738/MST_CONTROL]
Sep 9 17:15:32........
There's a lot of information and guides on OCFS2 for RHELand Centos Linux but the package setup and configuration is slightly different and this has thrown some people off.
You should install the following packages to get started:
apt-get install ocfs2-tools ocfs2console
In RHEL/Centos the main configuration file is located in /etc/sysconfig/o2cb
However in Debian based Linux it is located........