Port of #7108 .
Sometimes, the `emqx_sys_mon:procinfo/1` might be called with
something that is not a port, like `[]`. Not sure on the conditions
for this to happen.
```
2022-02-18T20:05:02.671592+00:00 [error] Generic server emqx_sys_mon terminating. Reason: {badarg,[{erlang,port_info,[[]],[{error_info,#{module => erl_erts_errors}}]},{emqx_sys_mon,portinfo,1,[{file,"/emqx/apps/emqx/src/emqx_sys_mon.erl"},{line,205}]},{emqx_sys_mon,'-handle_info/2-fun-5-',2,[{file,"/emqx/apps/emqx/src/emqx_sys_mon.erl"},{line,150}]},{emqx_sys_mon,suppress,3,[{file,"/emqx/apps/emqx/src/emqx_sys_mon.erl"},{line,184}]},{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,695}]},{gen_server,handle_msg,6,[{file,"gen_server.erl"},{line,771}]},{proc_lib,wake_up,3,[{file,"proc_lib.erl"},{line,236}]}]}. Last message: {monitor,<0.7796.0>,busy_dist_port,[]}. State: #{events => [{busy_dist_port,#Port<0.127>}],timer => #Ref<0.2758388682.1853620226.133920>}.
```
Without passing an empty argument list to `emqx_ctl:print`, formatting
instructions like `~n` are being printed literally.
```
Ignore.~nJoin the cluster successfully.~nCluster status: #{running_nodes =>
['emqx@emqx-0.int.thalesmg','emqx@emqx-1.int.thalesmg',
'emqx@emqx-2.int.thalesmg','emqx@emqx-3.int.thalesmg',
'emqx@emqx-4.int.thalesmg'],
stopped_nodes => []}
```
As described in the 5.0 specification, we should disconnect clients that
exceed the receive-maximum limit.
> If it receives more than Receive Maximum QoS 1 and QoS 2 PUBLISH packets
where it has not sent a PUBACK or PUBCOMP in response, **the Server uses a
DISCONNECT packet with Reason Code 0x9**
fix: #6447
When multiple clients try to connect concurrently using the same
client ID, they all call `emqx_channel:ensure_connected`, increasing
the live connection count, but only one will successfully acquire the
lock for that client ID. This means that all other clients that
increased the live connection count will not get to call neither
`emqx_channel:ensure_disconnected` nor be monitored for `DOWN`
messages, effectively causing a count leak.
By moving the increment to `emqx_cm:register_channel`, which is only
called inside the lock, we can remove this leakage.
Also, during the handling of `DOWN` messages, we now iterate over all
channel PIDs returned by `eqmx_misc:drain_down`, since it could be
that one or more PIDs are not contained in the `pmon` state.
* refactor(emqx_slow_subs): refactor use moving average
* fix(emqx_slow_subs): change elapsed to latency, and fix some error
* fix(emqx_slow_subs): fix emqx_mgmt_api.erl indent
* fix(emqx_slow_subs): change api name
* fix(emqx_slow_subs): fix and improve some code
* fix(emqx_slow_subs): move clienid filed from latency_stats to session
(Same as #6289 )
This adds the information from `proc_lib:initial_call/1` and the
current stacktrace from the process info to `emqx_sys_mon:procinfo/1`
to aid in debugging some warnings with no context such as the
following:
```
2021-11-23T12:33:59.387818+00:00 [warning] info: [{old_heap_block_size,45988046},{heap_block_size,22177879},{mbuf_size,0},{stack_size,40},{old_heap_size,22354134},{heap_size,7106339}], line: 130, mfa: emqx_sys_mon:handle_info/2, msg: large_heap, procinfo: [{pid,<0.2667.0>},{memory,579763664},{total_heap_size,68510672},{heap_size,22177879},{stack_size,40},{min_heap_size,233},{initial_call,{proc_lib,init_p,5}},{current_function,{gen,do_call,4}},{registered_name,[]},{status,running},{message_queue_len,360945},{group_leader,<0.1660.0>},{priority,normal},{trap_exit,false},{reductions,16493271},{last_calls,false},{catchlevel,4},{trace,0},{suspending,[]},{sequential_trace_token,[]},{error_handler,error_handler}]
```
JianBo He