My redis cluster keep on switching the master. Below are the logs.
4580:X 26 Aug 2021 20:51:57.673 # +switch-master mymaster IP1 6379 IP3 6379
4580:X 26 Aug 2021 20:51:57.673 * +slave slave IP2:6379 IP2 6379 # mymaster IP3 6379
4580:X 26 Aug 2021 20:51:57.673 * +slave slave IP1:6379 IP1 6379 # mymaster IP3 6379
4580:X 26 Aug 2021 20:59:33.956 # +sdown slave IP1:6379 IP1 6379 # mymaster IP3 6379
4580:X 26 Aug 2021 21:00:39.950 # -sdown slave IP1:6379 IP1 6379 # mymaster IP3 6379
4580:X 26 Aug 2021 21:16:44.989 # +new-epoch 3741
4580:X 26 Aug 2021 21:16:44.991 # +vote-for-leader 3df3b3dbeb6fabb0bc24da5adaa41209d1be9997 3741
4580:X 26 Aug 2021 21:16:45.083 # +sdown master mymaster IP3 6379
4580:X 26 Aug 2021 21:16:45.166 # +odown master mymaster IP3 6379 #quorum 3/2
4580:X 26 Aug 2021 21:16:45.166 # Next failover delay: I will not start a failover before Thu Aug 26 21:17:21 2021
4580:X 26 Aug 2021 21:16:46.074 # +config-update-from sentinel 3df3b3dbeb6fabb0bc24da5adaa41209d1be9997 IP2 26379 # mymaster IP3 6379
4580:X 26 Aug 2021 21:16:46.074 # +switch-master mymaster IP3 6379 IP1 6379
4580:X 26 Aug 2021 21:16:46.075 * +slave slave IP2:6379 IP2 6379 # mymaster IP1 6379
Related
I'm having a strange Redis issue that causes my redis db0 to get completely wiped periodically for no obvious reason.
I'm using redis with Bull queue for NestJS and inserting volatile keys with 7 days duration.
Everything is hosted on Google Cloud Kubernetes.
As you can see from the logs, queue fills up steadily and all of a sudden its wiped to 0.
1:M 14 Dec 2022 18:02:53.786 - Accepted 10.132.15.228:46851
1:M 14 Dec 2022 18:02:55.818 * DB saved on disk
1:M 14 Dec 2022 18:02:55.836 - DB 0: 6539 keys (1179 volatil
...skipping 1 line
1:M 14 Dec 2022 18:02:55.836 . 25 clients connected (0 repli
cas), 10264320 bytes in use
1:M 14 Dec 2022 18:02:56.338 * DB saved on disk
1:M 14 Dec 2022 18:02:57.975 * DB saved on disk
1:M 14 Dec 2022 18:02:58.444 * DB saved on disk
1:M 14 Dec 2022 18:02:58.687 * DB saved on disk
1:M 14 Dec 2022 18:03:00.863 - DB 0: 10 keys (3 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:00.863 . 25 clients connected (0 repli
cas), 3440672 bytes in use
1:M 14 Dec 2022 18:03:01.056 * DB saved on disk
This part is out of time, like 2 threads are writing to same output:
1:M 14 Dec 2022 18:03:10.900 - DB 0: 12 keys (5 volatile) in ...back 1 page
1:M 14 Dec 2022 18:02:40.773 - DB 0: 6542 keys (1174 volatile) in 8192 slots HT.
Any insights would be greatly appreciated.
Server info:
redis_version:7.0.6
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:68a9a9d6a665b45c
redis_mode:standalone
os:Linux 5.10.133+ x86_64
arch_bits:64
monotonic_clock:POSIX clock_gettime
multiplexing_api:epoll
atomicvar_api:c11-builtin
gcc_version:10.2.1
process_id:1
process_supervised:no
run_id:ca394137bd91b23622a8facfb97ae86ba2325a01
tcp_port:6379
server_time_usec:1671042411041619
uptime_in_seconds:1752
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:10098026
executable:/data/redis-server
config_file:/redis-config/redis.conf
io_threads_active:0
# Clients
connected_clients:25
cluster_connections:0
Redis config:
save 60 1000
loglevel debug
notify-keyspace-events Ex
dbfilename dump.rdb
dir /data
logfile /data/redis.log
Debug log:
...skipping 1 line
1:M 14 Dec 2022 17:59:55.106 . 24 clients connected (0 repli
cas), 8023104 bytes in use
1:M 14 Dec 2022 18:00:00.125 - DB 0: 5552 keys (1125 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:00.126 . 24 clients connected (0 repli
cas), 7959688 bytes in use
1:M 14 Dec 2022 18:00:05.146 - DB 0: 5552 keys (1128 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:05.146 . 24 clients connected (0 repli
cas), 8038576 bytes in use
1:M 14 Dec 2022 18:00:10.166 - DB 0: 5553 keys (1128 volatil
...skipping 1 line
1:M 14 Dec 2022 18:00:10.166 . 24 clients connected (0 repli
cas), 7977384 bytes in use
1:M 14 Dec 2022 18:00:14.281 * 1000 changes in 60 seconds. S
aving...
1:M 14 Dec 2022 18:00:14.282 * Background saving started by
pid 26
26:C 14 Dec 2022 18:00:14.284 - Fork CoW for RDB: current 0
MB, peak 0 MB, average 0 MB
26:C 14 Dec 2022 18:00:14.378 * DB saved on disk
26:C 14 Dec 2022 18:00:14.378 * Fork CoW for RDB: current 0
MB, peak 0 MB, average 0 MB
...skipping 1 line
1:M 14 Dec 2022 18:00:15.187 - DB 0: 6081 keys (1128 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:15.187 . 24 clients connected (0 repli
cas), 9276960 bytes in use
1:M 14 Dec 2022 18:00:17.755 - Accepted 10.8.1.1:36758
1:M 14 Dec 2022 18:00:20.208 - DB 0: 6570 keys (1131 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:20.208 . 24 clients connected (0 repli
cas), 10252224 bytes in use
1:M 14 Dec 2022 18:00:25.227 - DB 0: 6570 keys (1133 volatil
e) in 8192 slots HT.
...skipping 1 line
1:M 14 Dec 2022 18:00:30.247 - DB 0: 6568 keys (1134 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:30.247 . 24 clients connected (0 repli
cas), 10266176 bytes in use
1:M 14 Dec 2022 18:00:35.267 - DB 0: 6568 keys (1137 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:35.267 . 24 clients connected (0 repli
cas), 10345096 bytes in use
1:M 14 Dec 2022 18:00:40.285 - DB 0: 6569 keys (1137 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:40.285 . 24 clients connected (0 repli
...skipping 1 line
1:M 14 Dec 2022 18:00:45.304 - DB 0: 6563 keys (1140 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:45.304 . 24 clients connected (0 repli
cas), 10315776 bytes in use
1:M 14 Dec 2022 18:00:50.325 - DB 0: 6563 keys (1140 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:50.325 . 24 clients connected (0 repli
cas), 10254504 bytes in use
1:M 14 Dec 2022 18:00:55.342 - DB 0: 6562 keys (1143 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:00:55.342 . 24 clients connected (0 repli
...skipping 1 line
1:M 14 Dec 2022 18:01:00.360 - DB 0: 6562 keys (1143 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:00.360 . 24 clients connected (0 repli
cas), 10209512 bytes in use
1:M 14 Dec 2022 18:01:05.381 - DB 0: 6562 keys (1146 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:05.381 . 24 clients connected (0 repli
cas), 10309016 bytes in use
1:M 14 Dec 2022 18:01:10.399 - DB 0: 6563 keys (1146 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:10.399 . 24 clients connected (0 repli
...skipping 1 line
1:M 14 Dec 2022 18:01:15.019 * 1000 changes in 60 seconds. S
aving...
1:M 14 Dec 2022 18:01:15.020 * Background saving started by
pid 27
27:C 14 Dec 2022 18:01:15.022 - Fork CoW for RDB: current 0
MB, peak 0 MB, average 0 MB
27:C 14 Dec 2022 18:01:15.085 * DB saved on disk
27:C 14 Dec 2022 18:01:15.086 * Fork CoW for RDB: current 0
MB, peak 0 MB, average 0 MB
1:M 14 Dec 2022 18:01:15.120 * Background saving terminated
with success
...skipping 1 line
1:M 14 Dec 2022 18:01:15.421 . 24 clients connected (0 repli
cas), 10212776 bytes in use
1:M 14 Dec 2022 18:01:20.441 - DB 0: 6553 keys (1149 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:20.441 . 24 clients connected (0 repli
cas), 10192304 bytes in use
1:M 14 Dec 2022 18:01:25.460 - DB 0: 6553 keys (1152 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:25.460 . 24 clients connected (0 repli
cas), 10189448 bytes in use
1:M 14 Dec 2022 18:01:30.479 - DB 0: 6553 keys (1152 volatil
...skipping 1 line
1:M 14 Dec 2022 18:01:30.479 . 24 clients connected (0 repli
cas), 10189448 bytes in use
1:M 14 Dec 2022 18:01:35.503 - DB 0: 6553 keys (1155 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:35.503 . 24 clients connected (0 repli
cas), 10186592 bytes in use
1:M 14 Dec 2022 18:01:40.523 - DB 0: 6553 keys (1155 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:40.523 . 24 clients connected (0 repli
cas), 10207064 bytes in use
1:M 14 Dec 2022 18:01:45.543 - DB 0: 6551 keys (1157 volatil
...skipping 1 line
1:M 14 Dec 2022 18:01:45.543 . 24 clients connected (0 repli
cas), 10202824 bytes in use
1:M 14 Dec 2022 18:01:50.561 - DB 0: 6551 keys (1157 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:50.561 . 24 clients connected (0 repli
cas), 10202824 bytes in use
1:M 14 Dec 2022 18:01:55.582 - DB 0: 6546 keys (1160 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:01:55.582 . 24 clients connected (0 repli
cas), 10173504 bytes in use
1:M 14 Dec 2022 18:02:00.603 - DB 0: 6546 keys (1161 volatil
...skipping 1 line
1:M 14 Dec 2022 18:02:00.603 . 24 clients connected (0 repli
cas), 10192880 bytes in use
1:M 14 Dec 2022 18:02:05.622 - DB 0: 6545 keys (1163 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:05.622 . 24 clients connected (0 repli
cas), 10169456 bytes in use
1:M 14 Dec 2022 18:02:10.645 - DB 0: 6546 keys (1167 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:10.645 . 24 clients connected (0 repli
cas), 10290056 bytes in use
1:M 14 Dec 2022 18:02:15.667 - DB 0: 6546 keys (1167 volatil
...skipping 1 line
1:M 14 Dec 2022 18:02:15.667 . 24 clients connected (0 repli
cas), 10208312 bytes in use
1:M 14 Dec 2022 18:02:20.690 - DB 0: 6546 keys (1167 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:20.690 . 24 clients connected (0 repli
cas), 10208312 bytes in use
1:M 14 Dec 2022 18:02:25.713 - DB 0: 6546 keys (1170 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:25.713 . 24 clients connected (0 repli
cas), 10184984 bytes in use
1:M 14 Dec 2022 18:02:30.731 - DB 0: 6545 keys (1171 volatil
...skipping 1 line
1:M 14 Dec 2022 18:02:30.731 . 24 clients connected (0 repli
cas), 10223352 bytes in use
1:M 14 Dec 2022 18:02:35.750 - DB 0: 6541 keys (1173 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:35.750 . 24 clients connected (0 repli
cas), 10154896 bytes in use
1:M 14 Dec 2022 18:02:40.773 - DB 0: 6542 keys (1174 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:40.773 . 24 clients connected (0 repli
cas), 10194824 bytes in use
1:M 14 Dec 2022 18:02:44.425 - Accepted 10.132.15.230:61177
...skipping 1 line
1:M 14 Dec 2022 18:02:45.793 - DB 0: 6541 keys (1176 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:45.793 . 24 clients connected (0 repli
cas), 10172512 bytes in use
1:M 14 Dec 2022 18:02:50.817 - DB 0: 6540 keys (1179 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:50.817 . 24 clients connected (0 repli
cas), 10250272 bytes in use
1:M 14 Dec 2022 18:02:53.786 - Accepted 10.132.15.228:46851
1:M 14 Dec 2022 18:02:55.818 * DB saved on disk
1:M 14 Dec 2022 18:02:55.836 - DB 0: 6539 keys (1179 volatil
...skipping 1 line
1:M 14 Dec 2022 18:02:55.836 . 25 clients connected (0 repli
cas), 10264320 bytes in use
1:M 14 Dec 2022 18:02:56.338 * DB saved on disk
1:M 14 Dec 2022 18:02:57.975 * DB saved on disk
1:M 14 Dec 2022 18:02:58.444 * DB saved on disk
1:M 14 Dec 2022 18:02:58.687 * DB saved on disk
1:M 14 Dec 2022 18:03:00.863 - DB 0: 10 keys (3 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:00.863 . 25 clients connected (0 repli
cas), 3440672 bytes in use
1:M 14 Dec 2022 18:03:01.056 * DB saved on disk
...skipping 1 line
1:M 14 Dec 2022 18:03:01.989 - Client closed connection id=2
9 addr=10.132.15.228:46851 laddr=10.8.1.41:6379 fd=32 name=
age=8 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=
0 qbuf-free=20474 argv-mem=0 multi-mem=0 rbs=1024 rbp=97 obl
=0 oll=0 omem=0 tot-mem=22272 events=r cmd=save user=default
redir=-1 resp=2
1:M 14 Dec 2022 18:03:05.882 - DB 0: 10 keys (3 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:05.882 . 24 clients connected (0 repli
cas), 3418912 bytes in use
1:M 14 Dec 2022 18:03:10.900 - DB 0: 12 keys (5 volatile) in
...back 1 page
1:M 14 Dec 2022 18:02:40.773 - DB 0: 6542 keys (1174 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:40.773 . 24 clients connected (0 repli
cas), 10194824 bytes in use
1:M 14 Dec 2022 18:02:44.425 - Accepted 10.132.15.230:61177
1:M 14 Dec 2022 18:02:44.639 - Reading from client: Connecti
on reset by peer
1:M 14 Dec 2022 18:02:45.793 - DB 0: 6541 keys (1176 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:45.793 . 24 clients connected (0 repli
cas), 10172512 bytes in use
...skipping 1 line
1:M 14 Dec 2022 18:02:50.817 . 24 clients connected (0 repli
cas), 10250272 bytes in use
1:M 14 Dec 2022 18:02:53.786 - Accepted 10.132.15.228:46851
1:M 14 Dec 2022 18:02:55.818 * DB saved on disk
1:M 14 Dec 2022 18:02:55.836 - DB 0: 6539 keys (1179 volatil
e) in 8192 slots HT.
1:M 14 Dec 2022 18:02:55.836 . 25 clients connected (0 repli
cas), 10264320 bytes in use
1:M 14 Dec 2022 18:02:56.338 * DB saved on disk
1:M 14 Dec 2022 18:02:57.975 * DB saved on disk
1:M 14 Dec 2022 18:02:58.444 * DB saved on disk
...skipping 1 line
1:M 14 Dec 2022 18:03:00.863 - DB 0: 10 keys (3 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:00.863 . 25 clients connected (0 repli
cas), 3440672 bytes in use
1:M 14 Dec 2022 18:03:01.056 * DB saved on disk
1:M 14 Dec 2022 18:03:01.756 * DB saved on disk
1:M 14 Dec 2022 18:03:01.989 - Client closed connection id=2
9 addr=10.132.15.228:46851 laddr=10.8.1.41:6379 fd=32 name=
age=8 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=
0 qbuf-free=20474 argv-mem=0 multi-mem=0 rbs=1024 rbp=97 obl
=0 oll=0 omem=0 tot-mem=22272 events=r cmd=save user=default
...skipping 1 line
1:M 14 Dec 2022 18:03:05.882 - DB 0: 10 keys (3 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:05.882 . 24 clients connected (0 repli
cas), 3418912 bytes in use
1:M 14 Dec 2022 18:03:10.900 - DB 0: 12 keys (5 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:10.900 . 24 clients connected (0 repli
cas), 3378320 bytes in use
1:M 14 Dec 2022 18:03:15.917 - DB 0: 12 keys (5 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:15.917 . 24 clients connected (0 repli
cas), 3378336 bytes in use
1:M 14 Dec 2022 18:03:20.936 - DB 0: 12 keys (5 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:20.936 . 24 clients connected (0 repli
cas), 3419296 bytes in use
1:M 14 Dec 2022 18:03:25.954 - DB 0: 12 keys (5 volatile) in
16 slots HT.
1:M 14 Dec 2022 18:03:25.954 . 24 clients connected (0 repli
cas), 3378304 bytes in use
I'm new to Redis and would like to play with the RedisTimeSeries module. Following the instructions I load the module using:
redis-server --loadmodule /path/to/module/redistimeseries.so
Obviously adjusting the path to match mine. The server starts and shows the following output:
88537:M 02 Apr 2022 12:19:24.785 # Server initialized
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> RedisTimeSeries version 10609, git_sha=f36e5a703dc9a2487880087a34f6cb0e56d9a459
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> Redis version found by RedisTimeSeries : 6.2.6 - oss
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> loaded default CHUNK_SIZE_BYTES policy: 4096
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> loaded server DUPLICATE_POLICY: block
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> Setting default series ENCODING to: compressed
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> Detected redis oss
88537:M 02 Apr 2022 12:19:24.789 * <timeseries> Enabled diskless replication
88537:M 02 Apr 2022 12:19:24.789 * Module 'timeseries' loaded from lib/redistimeseries.so
88537:M 02 Apr 2022 12:19:24.790 * Loading RDB produced by version 6.2.6
88537:M 02 Apr 2022 12:19:24.790 * RDB age 4 seconds
88537:M 02 Apr 2022 12:19:24.790 * RDB memory usage when created 1.02 Mb
88537:M 02 Apr 2022 12:19:24.790 # Done loading RDB, keys loaded: 0, keys expired: 0.
88537:M 02 Apr 2022 12:19:24.790 * DB loaded from disk: 0.000 seconds
88537:M 02 Apr 2022 12:19:24.790 * Ready to accept connections
When I connect using the redis-cli I run the sample command like so:
TS.CREATE temperature RETENTION 60 LABELS sensor_id 2 area_id 32
However, I receive the following error in the CLI:
(error) ERR unknown command `TS.CREATE`, with args beginning with: `temperature`, `RETENTION`, `60`, `LABELS`, `sensor_id`, `2`, `area_id`, `32`,
No time series commands are available. Can anyone help? I'm stumped.
I'm new to supporting WAS (Websphere Application Server), currently I'm having issue with my WAS, my WAS was installed under AIX under 2 servers/nodes.
While investigating it, I found in our application log that there are some activity which is "Performing Cache Maintenance":
===================================
2017-01-14 01:31:52,619: [Cache Maintenance] com.ibm.srm.util.db.ServerCache refreshed 2017-01-14 01:31:53,314: [Cache Maintenance] Memory: available=[6884mb] used=[9500mb] %used avail=[58%] max=[16384mb] %used max=[58%] total=[16384mb] free=[6884mb] used by doMaintenance=[-251,201,3 92bytes] Time=[22,818ms] 2017-01-14 01:51:53,325: -------- Performing Cache Maintenance -------- 2017-01-14 01:51:53,325: null : QN=319 Select * from perform.cache_timestamps where row_class_name not like '%Cache' and row_class_name not like '%(SRM 6.0)' 2017-01-14 01:51:53,333: Returning 19 data records, QN=319,2 columns, Time: 8ms conn/query time: 5ms
2017-01-14 01:51:53,333: [Cache Maintenance] Memory: available=[5492mb] used=[10892mb] %used avail=[66%] max=[16384mb] %used max=[66%] total=[16384mb] free=[5492mb] used by doMaintenance=[532kb] Time=[8ms]
===================================
After this activity triggered, I found that mpmstats value for 'bsy' are keep increasing until reach MaxClient maximum value which is '4000':
===================================
[Sat Jan 14 01:38:58 2017] [notice] mpmstats: rdy 166 bsy 234 rd 0 wr 234 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 01:38:58 2017] [notice] mpmstats: bsy: 234 in mod_was_ap22_http.c [Sat Jan 14 01:48:58 2017] [notice] mpmstats: rdy 195 bsy 505 rd 0 wr 505 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 01:48:58 2017] [notice] mpmstats: bsy: 505 in mod_was_ap22_http.c [Sat Jan 14 01:58:58 2017] [notice] mpmstats: rdy 180 bsy 720 rd 0 wr 720 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 01:58:58 2017] [notice] mpmstats: bsy: 720 in mod_was_ap22_http.c [Sat Jan 14 02:08:59 2017] [notice] mpmstats: rdy 105 bsy 895 rd 1 wr 894 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 02:08:59 2017] [notice] mpmstats: bsy: 894 in mod_was_ap22_http.c [Sat Jan 14 02:18:59 2017] [notice] mpmstats: rdy 112 bsy 1088 rd 1 wr 1087 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 02:18:59 2017] [notice] mpmstats: bsy: 1087 in mod_was_ap22_http.c
[Sat Jan 14 02:28:59 2017] [notice] mpmstats: rdy 158 bsy 1242 rd 1 wr 1241 ka 0 log 0 dns 0 cls 0
----
[Sat Jan 14 04:55:34 2017] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 04:55:34 2017] [notice] mpmstats: bsy: 4000 in mod_was_ap22_http.c [Sat Jan 14 04:57:04 2017] [notice] mpmstats: reached MaxClients (4000/4000) [Sat Jan 14 04:57:04 2017] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0 [Sat Jan 14 04:57:04 2017] [notice] mpmstats: bsy: 4000 in mod_was_ap22_http.c [Sat Jan 14 04:58:34 2017] [notice] mpmstats: reached MaxClients (4000/4000) [Sat Jan 14 04:58:34 2017] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Sat Jan 14 04:58:34 2017] [notice] mpmstats: bsy: 4000 in mod_was_ap22_http.c
===================================
It seem WAS are not processing the client request until it reached the Maximum value.
The questions are:
Is there any log that I can check about why WAS are not processing the Client request until it reached to the max value?
Does the "Cache Maintenance" activity hold WAS from processing the Client request? Because as mentioned from our developer this activity should not lead to this issue.
What is the procedure that I can take to identify/resolve this issue?
Appreciate if can help me for this thing as this issue already occurred for a long time but still not resolve.
OS: SLes 11 sp4
syslog-ng: syslog-ng-2.0.9-27.34.39.2
Hi,
syslog-ng is configured to read from a application log file and then send it to another file in /var/log (tcpdump is not installed, I cant install it on a blackbox so this is how I test my config)
I have the following in my syslog-ng configuration file:
source ESRS {
file("/opt/esrsve/gateway/xGate.log");
};
destination esrsfile{ file("/var/log/max.log" );};
log { source(ESRS);
destination(esrsfile);
};
The problem I am seeing is that when syslog writes to the outputfile (esrsfile) it truncatedthe lines.
ex: Source File :
[ 0, 6, 1, 1007] 08-29-2016 13:56:28.703 IMPORTANT INFO EDDEMC: Data Item::PMStatus Current Value::Offline
And the destination file looiks like this:
...
...
Aug 29 14:00:02 hostname C
Aug 29 14:00:02 hostname u
Aug 29 14:00:02 hostname r
Aug 29 14:00:02 hostname r
Aug 29 14:00:02 hostname e
Aug 29 14:00:02 hostname n
Aug 29 14:00:02 hostname t
Aug 29 14:00:02 hostname
Aug 29 14:00:02 hostname V
Aug 29 14:00:02 hostname a
Aug 29 14:00:02 hostname l
Aug 29 14:00:02 hostname u
Aug 29 14:00:02 hostname e
Aug 29 14:00:02 hostname :
Aug 29 14:00:02 hostname :
Aug 29 14:00:02 hostname O
Aug 29 14:00:02 hostname f
Aug 29 14:00:02 hostname f
Aug 29 14:00:02 hostname l
Aug 29 14:00:02 hostname i
Aug 29 14:00:02 hostname n
Aug 29 14:00:02 hostname e
...
...
What is wrong here please?
When you look closely, the lines are not truncated, but one log entry spreads over multiple lines, character by character. It happens usually, when the log writer flushes after writing every single character.
Make sure the writer buffers lines and sends them as one single message.
I am trying to use Axis2/c on OS X but when I launch axis2c_http_server, I get the following errors:
[Fri Mar 16 12:26:19 2012] [info] Starting Axis2 HTTP server....
[Fri Mar 16 12:26:19 2012] [info] Apache Axis2/C version in use : 1.6.0
[Fri Mar 16 12:26:19 2012] [info] Server port : 9090
[Fri Mar 16 12:26:19 2012] [info] Repo location : ../
[Fri Mar 16 12:26:19 2012] [info] Read Timeout : 60000 ms
[Fri Mar 16 12:26:19 2012] [error] dep_engine.c(324) Axis2 Configuration file name not found
[Fri Mar 16 12:26:19 2012] [error] conf_init.c(56) Creating deployment engine failed for repository ../
[Fri Mar 16 12:26:19 2012] [error] http_receiver.c(126) unable to create private configuration contextfor repo path ../
[Fri Mar 16 12:26:19 2012] [error] http_server_main.c(215) Server creation failed: Error code: 18 :: Configuration file cannot be found
It seems the server cannot locate the file axis2.xml.
I have put axis2.xml in the repo's root. I have correctly set the environment variable $AXIS2C_HOME because the server write the logs in the right folder.
Here is my repo's structure:
antoine#Antoines-MacBook-Air:repo $ pwd
/Users/antoine/Documents/axis2c_test/repo
antoine#Antoines-MacBook-Air:repo $ ll -R
total 16
-rw-r--r--# 1 antoine staff 5.8K Mar 16 10:06 axis2.xml
drwxr-xr-x 53 antoine staff 1.8K Mar 16 10:06 lib
drwxr-xr-x 4 antoine staff 136B Mar 16 12:26 logs
drwxr-xr-x 4 antoine staff 136B Mar 16 11:14 services
./lib:
total 25816
-rwxr-xr-x 1 antoine staff 246K Mar 16 10:06 libaxis2_axiom.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 246K Mar 16 10:06 libaxis2_axiom.0.dylib
-rw-r--r-- 1 antoine staff 1.3M Mar 16 10:06 libaxis2_axiom.a
-rwxr-xr-x 1 antoine staff 246K Mar 16 10:06 libaxis2_axiom.dylib
-rwxr-xr-x 1 antoine staff 1.0K Mar 16 10:06 libaxis2_axiom.la
-rwxr-xr-x 1 antoine staff 576K Mar 16 10:06 libaxis2_engine.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 576K Mar 16 10:06 libaxis2_engine.0.dylib
-rw-r--r-- 1 antoine staff 2.6M Mar 16 10:06 libaxis2_engine.a
-rwxr-xr-x 1 antoine staff 576K Mar 16 10:06 libaxis2_engine.dylib
-rwxr-xr-x 1 antoine staff 1.1K Mar 16 10:06 libaxis2_engine.la
-rwxr-xr-x 1 antoine staff 120K Mar 16 10:06 libaxis2_http_common.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 120K Mar 16 10:06 libaxis2_http_common.0.dylib
-rw-r--r-- 1 antoine staff 484K Mar 16 10:06 libaxis2_http_common.a
-rwxr-xr-x 1 antoine staff 120K Mar 16 10:06 libaxis2_http_common.dylib
-rwxr-xr-x 1 antoine staff 1.1K Mar 16 10:06 libaxis2_http_common.la
-rwxr-xr-x 1 antoine staff 20K Mar 16 10:06 libaxis2_http_receiver.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 20K Mar 16 10:06 libaxis2_http_receiver.0.dylib
-rw-r--r-- 1 antoine staff 57K Mar 16 10:06 libaxis2_http_receiver.a
-rwxr-xr-x 1 antoine staff 20K Mar 16 10:06 libaxis2_http_receiver.dylib
-rwxr-xr-x 1 antoine staff 1.2K Mar 16 10:06 libaxis2_http_receiver.la
-rwxr-xr-x 1 antoine staff 112K Mar 16 10:06 libaxis2_http_sender.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 112K Mar 16 10:06 libaxis2_http_sender.0.dylib
-rw-r--r-- 1 antoine staff 355K Mar 16 10:06 libaxis2_http_sender.a
-rwxr-xr-x 1 antoine staff 112K Mar 16 10:06 libaxis2_http_sender.dylib
-rwxr-xr-x 1 antoine staff 1.2K Mar 16 10:06 libaxis2_http_sender.la
-rwxr-xr-x 1 antoine staff 49K Mar 16 10:06 libaxis2_parser.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 49K Mar 16 10:06 libaxis2_parser.0.dylib
-rw-r--r-- 1 antoine staff 139K Mar 16 10:06 libaxis2_parser.a
-rwxr-xr-x 1 antoine staff 49K Mar 16 10:06 libaxis2_parser.dylib
-rwxr-xr-x 1 antoine staff 982B Mar 16 10:06 libaxis2_parser.la
-rwxr-xr-x 1 antoine staff 57K Mar 16 10:06 libaxis2_xpath.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 57K Mar 16 10:06 libaxis2_xpath.0.dylib
-rw-r--r-- 1 antoine staff 190K Mar 16 10:06 libaxis2_xpath.a
-rwxr-xr-x 1 antoine staff 57K Mar 16 10:06 libaxis2_xpath.dylib
-rwxr-xr-x 1 antoine staff 902B Mar 16 10:06 libaxis2_xpath.la
-rwxr-xr-x 1 antoine staff 193K Mar 16 10:06 libaxutil.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 193K Mar 16 10:06 libaxutil.0.dylib
-rw-r--r-- 1 antoine staff 982K Mar 16 10:06 libaxutil.a
-rwxr-xr-x 1 antoine staff 193K Mar 16 10:06 libaxutil.dylib
-rwxr-xr-x 1 antoine staff 867B Mar 16 10:06 libaxutil.la
-rwxr-xr-x 1 antoine staff 63K Mar 16 10:06 libguththila.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 63K Mar 16 10:06 libguththila.0.dylib
-rw-r--r-- 1 antoine staff 191K Mar 16 10:06 libguththila.a
-rwxr-xr-x 1 antoine staff 63K Mar 16 10:06 libguththila.dylib
-rwxr-xr-x 1 antoine staff 923B Mar 16 10:06 libguththila.la
-rwxr-xr-x 1 antoine staff 229K Mar 16 10:06 libneethi.0.6.0.dylib
-rwxr-xr-x 1 antoine staff 229K Mar 16 10:06 libneethi.0.dylib
-rw-r--r-- 1 antoine staff 1.4M Mar 16 10:06 libneethi.a
-rwxr-xr-x 1 antoine staff 229K Mar 16 10:06 libneethi.dylib
-rwxr-xr-x 1 antoine staff 1.0K Mar 16 10:06 libneethi.la
drwxr-xr-x 3 antoine staff 102B Mar 16 10:06 pkgconfig
./lib/pkgconfig:
total 8
-rw-r--r-- 1 antoine staff 256B Mar 16 10:06 axis2c.pc
./logs:
total 24
-rw-r--r-- 1 antoine staff 12K Mar 16 12:26 axis2.log
./services:
total 32
-rwxr-xr-x 1 antoine staff 10K Mar 16 12:26 libhello.dylib
-rw-r--r-- 1 antoine staff 209B Mar 16 10:06 services.xml
Does someone see what I am doing wrong?
I am using the client side consumer only, but maybe the solution I have can help you.
In order to run the server you need to set AXIS2C_HOME environment variable to point to the AXIS2C installation.
For the client you don't need to, you just specifiy the location of the axis2.xml file when creating a new instance of axis2c_stub_t type (aka set the client_home parameter.)