Jiffies not zero on boot - linux

After reboot the jiffies are not initialized to zero, but instead to some high value (near the wrap-around).
For example (immediately after reboot):
cat /proc/timer_list | grep jiffies
.idle_jiffies : 4294902561
.last_jiffies : 4294902561
.next_jiffies : 4294902623
jiffies: 4294902561
.idle_jiffies : 4294902561
.last_jiffies : 4294902561
.next_jiffies : 4294902568
jiffies: 4294902561
.idle_jiffies : 4294902561
.last_jiffies : 4294902561
.next_jiffies : 4294902679
jiffies: 4294902561
.idle_jiffies : 4294902561
.last_jiffies : 4294902561
.next_jiffies : 4294902607
What am I missing? I am running Ubuntu 12.04 LTS, 3.13.0-36-generic. Thanks!

At the boot jiffies is not initalized by zero, it is initalized by INITIAL_JIFFIES constant.
You can see this constant in linux kernel headers:
$ cd your_path_to_linux_kernel_headers
$ grep INITIAL_JIFFIES linux/jiffies.h
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
It was introduced by this patch to help detect problems related to that very overflow.
Sorry for long waiting for answer. :)

Related

Recover informations from CSV files with my awk script

I have this CSV files :
Monday,linux,6,0.2
Tuesday,linux,0.25,0.2
Wednesday,linux,64,3
I create a little script that allow me to recover the informations from my csv
and to place them like this :
Day : Monday
OS : Linux
RAM : 6
CPU1 : 0.2
My script is :
#!/bin/bash
awk -F'[ ,;|.]' 'FNR==0{next}
FNR>1 {
print "DAY : " $1;
print "OS :\n " $2
print "RAM :\n " $3
print "CPU1 :\n " $4
}' mycsvfile.csv
But the result is :
DAY : Tuesday
OS :
linux
RAM :
0
CPU1 :
25
DAY : Wednesday
OS :
linux
RAM :
64
CPU1
Or I want :
DAY : Monday
OS : linux
RAM : 0.2
CPU 1 : 1
DAY : Tuesday
OS : linux
RAM : 0.25
CPU 1 : 0.2
DAY : Wednesday
OS : linux
RAM : 64
CPU 1 : 3
Can you tell me why my script doesn't works and why floats are not taken into account ?
Thank you !
Added tab and newline to same awk as Cyrus posted.
awk -F ',' '{
print "DAY :",$1
print "OS :",$2
print "RAM :",$3
print "CPU1 :",$4"\n"
}' OFS='\t' file
DAY : Monday
OS : linux
RAM : 6
CPU1 : 0.2
DAY : Tuesday
OS : linux
RAM : 0.25
CPU1 : 0.2
DAY : Wednesday
OS : linux
RAM : 64
CPU1 : 3
A more generic solution:
awk -F, 'BEGIN {split("DAY OS RAM CPU", header, " ")}{for (i=1;i<=4;i++) print header[i]":\t",$i;print ""}' t
DAY: Monday
OS: linux
RAM: 6
CPU: 0.2
DAY: Tuesday
OS: linux
RAM: 0.25
CPU: 0.2
DAY: Wednesday
OS: linux
RAM: 64
CPU: 3
More readable:
awk -F, '
BEGIN {split("DAY OS RAM CPU", header, " ")}
{
for (i=1;i<=4;i++)
print header[i]":\t",$i;
print ""
}' file

tickless kernel , isolcpus,nohz_full,and rcu_nocbs

I have add "isolcpus=3 nohz_full=3 rcu_nocbs=3" in grub.conf in
RedHat 7.1 , kernel: linux 3.10.0-229 kernel and according to http://www.breakage.org/2013/11/15/nohz_fullgodmode/
I also execute the following command :
cat /sys/bus/workqueue/devices/writeback/cpumask
f
echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
cat /sys/bus/workqueue/devices/writeback/numa
1
echo 0 > /sys/bus/workqueue/devices/writeback/numa
The box has only 4 cpu cores , I run the following shell :
watch -d 'cat /proc/interrupts'
look like work perfect , only cpu0 Local timer interrupts has 2000 per 2 secs,
the else cpu 1 to cpu 3 has less than 10 per 2 secs .
and then I test the following source :
void *Thread2(void *param)
{
pthread_detach(pthread_self());
while( 1 ){
sleep( 100000 ) ;
}
}
void *Thread1(void *param)
{
pthread_detach(pthread_self());
while( 1 ){
;
}
}
int main(int argc, char** argv)
{
pthread_t tid ;
pthread_create(&tid , NULL, Thread1, (void*)(long)3);
pthread_create(&tid , NULL, Thread2, (void*)(long)3);
while( 1 )
sleep( 5 ) ;
}
and run it by :
taskset -c 3 ./x1.exe
watch the output in :
watch -d 'cat /proc/interrupts'
this time , cpu 3 get 10~30 Local timer interrupts per 2 secs , look fine,
then I try to run 2 thread1 by :
pthread_create(&tid , NULL, Thread1, (void*)(long)3);
pthread_create(&tid , NULL, Thread1, (void*)(long)3);
then again run it :
taskset -c 3 ./x1.exe
then I watch the core 3 has the same Local timer interrupts with core 0 ,
it is 2000 interrupts per 2 secs .
May I ask , why 2 very busy thread1 will cause core 3 has
much more timer interrupts ?! what cause this happened ?!
and how to modify it if it can be ?!
In the second case, Kernel needs to schedule 2 cpu bound tasks on core 3 and the dynamic ticks configuration is applicable only when there is exactly one runnable task.
I thought SCHED_FIFO would stop these interrupts (and so I started answering), but that isn't yet implemented as per https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
There is no way to change this behaviour except scheduling threads on different CPUs. You can always hack the kernel to achieve what you need.

How do I find out how many CPUs (vcpus) my XEN system has?

If I start top or look into /proc/cpuinfo, I see only two CPUs. If I view the values displayed for my system with virt-manager, that tool shows me 32 vcpus (which is the value I think is correct).
I failed (yet) to find out on a script-level on the hypervisor that correct value (32). I have been looking into /proc/cpuinfo and /sys/devices/system/cpu/ and other things I could think of, but found that value nowhere. Also the shell commands like xen or xm I examined closely, but found no way to display the value I'm looking for.
Does anybody know how I can find out how many vcpus my XEN system provides?
EDIT: lscpu gives me:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 45
Stepping: 7
CPU MHz: 2900.086
BogoMIPS: 5800.17
Hypervisor vendor: Xen
Virtualization type: none
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 20480K
NUMA node0 CPU(s): 0,1
So, this also does not show the "32" anywhere.
The contents of /proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 # 2.90GHz
stepping : 7
microcode : 0x70d
cpu MHz : 2900.086
cache size : 20480 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq est ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat pln pts dtherm
bogomips : 5800.17
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2690 0 # 2.90GHz
stepping : 7
microcode : 0x70d
cpu MHz : 2900.086
cache size : 20480 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq est ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat pln pts dtherm
bogomips : 5800.17
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
I found a way now:
IFS=: read _ nr_cpus < <(xm info | grep ^nr_cpus)
echo "$nr_cpus"
This will (finally) print
32
on my system.
This is a nice way:
cat /proc/cpuinfo | grep "core id"
This is an example of the output:
core id : 0
core id : 1
core id : 0
core id : 1
In my case, the system is dual-core, I have only core-id 0 and core-id 1.

How to fix too many open files error when aggregating billions of records

I got the following error
opening file "/workspace/mongo/data/_tmp/extsort.63355": errno:24 Too many open files
How could I fix this error ?
Because the opened files is alreaday 63355 ?
2015-05-02T08:01:40.490+0000 I COMMAND [conn1] command sandbox.$cmd command: listCollections { listCollections: 1.0 } keyUpdates:0 writeConflicts:0 numYields:0 reslen:411 locks:{} 169ms
2015-05-02T15:01:02.060+0000 I - [conn2] Assertion: 16818:error opening file "/workspace/mongo/data/_tmp/extsort.63355": errno:24 Too many open files
2015-05-02T15:01:02.235+0000 I CONTROL [conn2]
0xf4d299 0xeeda71 0xed2d3f 0xed2dec 0xb3f453 0xb3c88c 0xb3d2dd 0xb3dfe2 0xb499c5 0xb49136 0xb7e3e6 0x987165 0x9d8b04 0x9d9aed 0x9da7fb 0xb9e956 0xab4d20 0x80e75d 0xf00e6b 0x7fe38e8b4182 0x7fe38d37c47d
----- BEGIN BACKTRACE -----
{"backtrace":[{"b":"400000","o":"B4D299"},{"b":"400000","o":"AEDA71"},{"b":"400000","o":"AD2D3F"},{"b":"400000","o":"AD2DEC"},{"b":"400000","o":"73F453"},{"b":"400000","o":"73C88C"},{"b":"400000","o":"73D2DD"},{"b":"400000","o":"73DFE2"},{"b":"400000","o":"7499C5"},{"b":"400000","o":"749136"},{"b":"400000","o":"77E3E6"},{"b":"400000","o":"587165"},{"b":"400000","o":"5D8B04"},{"b":"400000","o":"5D9AED"},{"b":"400000","o":"5DA7FB"},{"b":"400000","o":"79E956"},{"b":"400000","o":"6B4D20"},{"b":"400000","o":"40E75D"},{"b":"400000","o":"B00E6B"},{"b":"7FE38E8AC000","o":"8182"},{"b":"7FE38D282000","o":"FA47D"}],"processInfo":{ "mongodbVersion" : "3.0.1", "gitVersion" : "534b5a3f9d10f00cd27737fbcd951032248b5952", "uname" : { "sysname" : "Linux", "release" : "3.13.0-44-generic", "version" : "#73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014", "machine" : "x86_64" }, "somap" : [ { "elfType" : 2, "b" : "400000", "buildId" : "C35E766AD226FC0C16CB0C3885EC3B59E288A3F2" }, { "b" : "7FFF448FE000", "elfType" : 3, "buildId" : "9D77366C6409A9EA266179080FA7C779EEA8A958" }, { "b" : "7FE38E8AC000", "path" : "/lib/x86_64-linux-gnu/libpthread.so.0", "elfType" : 3, "buildId" : "9318E8AF0BFBE444731BB0461202EF57F7C39542" }, { "b" : "7FE38E64E000", "path" : "/lib/x86_64-linux-gnu/libssl.so.1.0.0", "elfType" : 3, "buildId" : "FF43D0947510134A8A494063A3C1CF3CEBB27791" }, { "b" : "7FE38E273000", "path" : "/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", "elfType" : 3, "buildId" : "B927879B878D90DD9FF4B15B00E7799AA8E0272F" }, { "b" : "7FE38E06B000", "path" : "/lib/x86_64-linux-gnu/librt.so.1", "elfType" : 3, "buildId" : "92FCF41EFE012D6186E31A59AD05BDBB487769AB" }, { "b" : "7FE38DE67000", "path" : "/lib/x86_64-linux-gnu/libdl.so.2", "elfType" : 3, "buildId" : "C1AE4CB7195D337A77A3C689051DABAA3980CA0C" }, { "b" : "7FE38DB63000", "path" : "/usr/lib/x86_64-linux-gnu/libstdc++.so.6", "elfType" : 3, "buildId" : "19EFDDAB11B3BF5C71570078C59F91CF6592CE9E" }, { "b" : "7FE38D85D000", "path" : "/lib/x86_64-linux-gnu/libm.so.6", "elfType" : 3, "buildId" : "1D76B71E905CB867B27CEF230FCB20F01A3178F5" }, { "b" : "7FE38D647000", "path" : "/lib/x86_64-linux-gnu/libgcc_s.so.1", "elfType" : 3, "buildId" : "8D0AA71411580EE6C08809695C3984769F25725B" }, { "b" : "7FE38D282000", "path" : "/lib/x86_64-linux-gnu/libc.so.6", "elfType" : 3, "buildId" : "30C94DC66A1FE95180C3D68D2B89E576D5AE213C" }, { "b" : "7FE38EACA000", "path" : "/lib64/ld-linux-x86-64.so.2", "elfType" : 3, "buildId" : "9F00581AB3C73E3AEA35995A0C50D24D59A01D47" } ] }}
mongod(_ZN5mongo15printStackTraceERSo+0x29) [0xf4d299]
mongod(_ZN5mongo10logContextEPKc+0xE1) [0xeeda71]
mongod(_ZN5mongo11msgassertedEiPKc+0xAF) [0xed2d3f]
mongod(+0xAD2DEC) [0xed2dec]
mongod(_ZN5mongo16SortedFileWriterINS_5ValueES1_EC1ERKNS_11SortOptionsERKSt4pairINS1_25SorterDeserializeSettingsES7_E+0x5D3) [0xb3f453]
mongod(_ZN5mongo19DocumentSourceGroup5spillEv+0x1BC) [0xb3c88c]
mongod(_ZN5mongo19DocumentSourceGroup8populateEv+0x46D) [0xb3d2dd]
mongod(_ZN5mongo19DocumentSourceGroup7getNextEv+0x292) [0xb3dfe2]
mongod(_ZN5mongo21DocumentSourceProject7getNextEv+0x45) [0xb499c5]
mongod(_ZN5mongo17DocumentSourceOut7getNextEv+0xD6) [0xb49136]
mongod(_ZN5mongo8Pipeline3runERNS_14BSONObjBuilderE+0xA6) [0xb7e3e6]
mongod(_ZN5mongo15PipelineCommand3runEPNS_16OperationContextERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x7A5) [0x987165]
mongod(_ZN5mongo12_execCommandEPNS_16OperationContextEPNS_7CommandERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x34) [0x9d8b04]
mongod(_ZN5mongo7Command11execCommandEPNS_16OperationContextEPS0_iPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0xC7D) [0x9d9aed]
mongod(_ZN5mongo12_runCommandsEPNS_16OperationContextEPKcRNS_7BSONObjERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x28B) [0x9da7fb]
mongod(_ZN5mongo8runQueryEPNS_16OperationContextERNS_7MessageERNS_12QueryMessageERKNS_15NamespaceStringERNS_5CurOpES3_+0x746) [0xb9e956]
mongod(_ZN5mongo16assembleResponseEPNS_16OperationContextERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0xB10) [0xab4d20]
mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0xDD) [0x80e75d]
mongod(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x34B) [0xf00e6b]
libpthread.so.0(+0x8182) [0x7fe38e8b4182]
libc.so.6(clone+0x6D) [0x7fe38d37c47d]
----- END BACKTRACE -----
2015-05-02T15:02:07.753+0000 I COMMAND [conn2] CMD: drop sandbox.tmp.agg_out.1
UPDATE
I typed ulimit -n unlimited on the console,
and modified the /etc/security/limits.conf with the following setting
* soft nofile unlimited
* hard nofile unlimited
* soft nproc unlimited
* hard nproc unlimited
check it by ulimit -a
health# ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-m: resident set size (kbytes) unlimited
-u: processes unlimited
-n: file descriptors 4096
-l: locked-in-memory size (kbytes) 64
-v: address space (kbytes) unlimited
-x: file locks unlimited
-i: pending signals 31538
-q: bytes in POSIX msg queues 819200
-e: max nice 0
-r: max rt priority 0
-N 15: unlimited
health# ulimit -Sn
4096
health# ulimit -Hn
4096
Is my system's setting alreday unlimited on open files ?
There is no clean answer for this as you are doing something very heavy stuff but workaround is available
ulimit is command in unix/linux which allows to set system limits for all properties.
in your case you need to increase max. no. of open files count or make it unlimited on safer side (it is also recommended by MongoDB)
ulimit -n <large value in your case 1000000>
or
sysctl -w fs.file-max=1000000
and
/etc/security/limits.conf or /etc/sysctl.conf:
change
fs.file-max = 1000000
I found that it was necessary to change the system-wide settings (using ulimit as suggested Nachiket Kate; another great description for Ubuntu may be found here) as well as the mongodb settings (as documented here).
For the sake of explanation, I'll summarize the commands I performed to get a handle on things (I'll reference the links again where they belong in the discussion).
Determine if the maximum number of file descriptors as enforced by the kernel are sufficient (the amount was sufficient)?
$ cat /proc/sys/fs/file-max
6569231
In my case this was not the problem. Checking the ulimit settings for the mongodb user revealed what the number of file descriptors were a paltry 1024:
$ sudo -H -u mongodb bash -c 'ulimit -a'
...
open files (-n) 1024
...
These values could be changed for all users by increasing the soft (user can modify them) and hard limits (I set mine quite high):
$ sudo su
$ echo -e "* hard\tnofile\t1000000\n* soft\tnofile\t990000" >> /etc/security/limits.conf
This may also be done on a user basis by replacing the * with the username. Although this worked on per-user basis, restarting the mongo daemon resulted in the number of file descriptors returning to 1024. It was necessary to follow the advice here regarding the pam session:
$ for file in /etc/pam.d/common-session*; do
echo 'session required pam_limits.so' >> $file
done
To test that the settings have been applied, I created a wee python script (placed in /tmp/file_descriptor_test.py):
#!/usr/bin/env python
n=990000
fd_list=list()
for i in range(1,n):
fd_list.append(open('/tmp/__%08d' % (i), 'w'))
print 'opened %d fds' % n
Running this as the mongodb user revealed that all was well system-wise:
sudo -H -u mongodb bash -c '/tmp/file_descriptor_test.py'
Traceback (most recent call last):
File "/tmp/fd.py", line 8, in <module>
IOError: [Errno 24] Too many open files: '/tmp/__00989998'
The files in /tmp/ may be deleted using
sudo find -type f -name '__*' -delete
as you'll be unable to list them properly (so rm doesn't work).
However, when running the offending mongo process, I still encountered the same Too many open files error. This led me to believe that the problem also lay with mongo (and led me, finally and embarrassingly to the excellent documentation. Editing the etc/systemd/system/multi-user.target.wants/mongodb-01.service and adding the following lines beneath [Service] directive
# (file size)
LimitFSIZE=infinity
# (cpu time)
LimitCPU=infinity
# (virtual memory size)
LimitAS=infinity
# (open files)
LimitNOFILE=990000
# (processes/threads)
LimitNPROC=495000
finally resolved the issue (remember to restart systemctl with sudo systemctl daemon-reload && systemctl restart mongodb-01.service). You can monitor the progress of the mongo process (mine was a temporary space hungry aggregate) via
$ while true; do echo $(find /var/lib/mongodb_01/_tmp/ | wc -l); sleep 1; done

How to finding all runnable processes

I'm learning about the scheduler and trying to print all runnable proceeses. So I have written a kernel module that uses the for_each_process macro to iterate over all processes, and prints the ones at "runnable" state. But this seems like a stupid (and inefficient) way of doing this. So I thought about getting a reference to all running queues and use their Red-Black-Tree to go over the runnable processes, but couldn't find a way to do this.
I have found out that there is a list of sched_classs for each CPU which are stop_sched_class->rt_sched_class->fair_sched_class->idle_sched_class and each one of them has it's own running queue. But couldn't find a way to reach them all.
I have used the module that uses the tasks_timeline to find all runnable processes, to print the address of the running queues - seems I have 3 running queues (while having only two processors).
The module:
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
#include <linux/sched.h>
MODULE_LICENSE("GPL");
struct cfs_rq {
struct load_weight load;
unsigned int nr_running, h_nr_running;
};
void printList(void){
int count;
struct task_struct * tsk;
count = 0;
for_each_process(tsk){
if(tsk->state)
continue;
printk("pid: %d rq: %p (%d)\n", tsk->pid, tsk->se.cfs_rq, tsk->se.cfs_rq->nr_running);
count++;
}
printk("count is: %d\n", count);
}
int init_module(void)
{
printList();
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world proc.\n");
}
The output:
[ 8215.627038] pid: 9147 ffff88007bbe9200 (3)
[ 8215.627043] pid: 9148 ffff8800369b0200 (2)
[ 8215.627045] pid: 9149 ffff8800369b0200 (2)
[ 8215.627047] pid: 9150 ffff88007bbe9200 (3)
[ 8215.627049] pid: 9151 ffff88007bbe9200 (3)
[ 8215.627051] pid: 9154 ffff8800a46d4600 (1)
[ 8215.627053] count is: 6
[ 8215.653741] Goodbye world proc.
About the computer:
$ uname -a
Linux k 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/cpuinfo | grep 'processor' | wc -l
2
So my questions are:
How can I print all runnable processes in a nicer way?
How are running queues made and managed?
Are the running queues somehow linked each other? (How?)
$ps -A -l and find the instance where both the process state (R) and the Process Flags (1) are as mentioned.
You can try this below cmd.
Sample output.
127:~$ ps -A -l | grep -e R -e D
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
1 S 0 1367 2 0 80 0 - 0 - ? 00:00:01 SEPDRV_ABNORMAL
4 R 1000 2634 2569 2 80 0 - 794239 - ? 00:25:06 Web Content
1 D 0 20091 2 0 80 0 - 0 - ? 00:00:00 kworker/3:2
4 R 1000 21077 9361 0 80 0 - 7229 - pts/17 00:00:00 ps

Resources