【发布时间】:2021-06-02 12:50:49
【问题描述】:
我已经启动了一个项目,我需要主动(一直)扫描 BLE 设备。我在 Linux 上,使用 Bluez 5.49,我使用 Python 与 dbus 1.10.20 进行通信)。 我能够开始扫描,使用 bluetoothctl 停止扫描并通过 DBus(BlueZ 接口的 GetManagedObjects())获取 BLE 广告数据。我遇到的问题是当我让扫描数小时时,dbus-deamon 开始占用越来越多的 RAM,我无法找到如何“刷新”dbus 从 BlueZ 收集的内容。最终 RAM 变满了,Linux 不高兴了。
所以我一直尝试不扫描,这可能会让垃圾收集器进行清理。没用。
我已编辑 /etc/dbus-1/system.d/bluetooth.conf 以删除任何我不需要的接口
<policy user="root">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
</policy>
这减缓了 RAM 的积累,但并没有解决问题。
我找到了一种方法来检查哪个连接有字节等待并确认它来自 blueZ
Connection :1.74 with pid 3622 '/usr/libexec/bluetooth/bluetoothd --experimental ' (org.bluez):
IncomingBytes=1253544
PeakIncomingBytes=1313072
OutgoingBytes=0
PeakOutgoingBytes=210
最后,我发现有人需要读取 DBus 中等待的内容才能释放内存。所以我发现了这个:https://*.com/a/60665430/15325057
我收到了 BlueZ 发送过来的数据,但内存仍在增加。
我知道释放 dbus 的唯一方法是重新启动 linux。这并不理想。
我对 DBus 的了解即将结束,这就是我今天来到这里的原因。 如果您有任何见解可以帮助我将 dbus 从 BlueZ 消息中解放出来,我们将不胜感激。
提前致谢
编辑添加我用来读取发现设备的 DBus 代码:
#!/usr/bin/python3
import dbus
BLUEZ_SERVICE_NAME = "org.bluez"
DBUS_OM_IFACE = "org.freedesktop.DBus.ObjectManager"
DEVICES_IFACE = "org.bluez.Device1"
def main_loop(subproc):
devinfo = None
objects = None
dbussys = dbus.SystemBus()
dbusconnection = dbussys.get_object(BLUEZ_SERVICE_NAME, "/")
bluezInterface = dbus.Interface(dbusconnection, DBUS_OM_IFACE)
while True:
try:
objects = bluezInterface.GetManagedObjects()
except dbus.DBusException as err:
print("dbus Error : " + str(err))
pass
all_devices = (str(path) for path, interfaces in objects.items() if DEVICES_IFACE in interfaces.keys())
for path, interfaces in objects.items():
if "org.bluez.Adapter1" not in interfaces.keys():
continue
device_list = [d for d in all_devices if d.startswith(path + "/")]
for dev_path in device_list:
properties = objects[dev_path][DEVICES_IFACE]
if "ServiceData" in properties.keys() and "Name" in properties.keys() and "RSSI" in properties.keys():
#[... Do someting...]
【问题讨论】:
-
你是如何测量内存积累的?我已经离开我的 RPi (BlueZ 5.50) 扫描了大约一个小时,我还没有看到内存填满。我用
watch -n20 free -m跟踪它。在我发现它们之后我做了一个RemoveDevice,但那是因为重复数据问题而不是内存。你的代码是什么样的?会不会是你的GetManagedObjects命令正在构建一个越来越大的列表? -
@ukBaz 我添加了用于读取已发现设备的代码。只是为了确保在 RAM 中占用更多空间的不是 python 代码,而是 dbus-daemon。我正在使用“top”来监控 dbus-daemon 并检查“RES”列。例如,扫描 dbus-daemon 一天的保留内存为 48196 Kb
-
@ukBaz 好吧,您可能适合 GetManagedObjects 的发展。我的脚本与 dbus-daemon 的大小差不多。但是我仍然如何首先释放 DBus 呢?我不再需要那里的数据,我只想对我的环境进行一次新的调查。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 280 message+ 20 0 49892 48196 2524 S 0.6 9.5 3:54.27 dbus-daemon 3692 root 20 0 46368 40408 6356 S 0.0 8.0 27:43.39 扫描仪。
标签: bluetooth-lowenergy dbus bluez