Install V6 on Ubuntu 22.04
Hi Team,
Trying to install V6.0 on Ubuntu 22.04 (Open source GPU with APT), but getting an error message at the Installation step-Download and add a GPG key to apt:
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). gpg: no valid OpenPGP data found.
What would be your recommendation?
Thanks, Laurent
-
I am also experiencing this issue - it appears the address where you are hosting the key is password protected "https://releases.heavy.ai/GPG-KEY-heavyai\
-
Hi @MurrMack @Laurent,
We are sorry for the problem you are facing, but it looks like it's wrong permission on the WebServer.
I'm sending a private message with a zipped file
Anyway, it's likely that you will face some issues on Ubuntu 22.04, because of the ldap library. The workaround is to patch executables with patchelf command this way
$ patchelf --replace-needed libldap-2.4.so.2 libldap.so initdb $ patchelf --replace-needed liblber-2.4.so.2 liblber.so initdb $ patchelf --replace-needed libldap-2.4.so.2 libldap.so omnisci_server $ patchelf --replace-needed liblber-2.4.so.2 liblber.so omnisci_serverRegards, Candido
-
Thanks Candido, i was able to add the unzipped key manually [gpg --import ~/GPG-KEY-heavyai] and progress successfully with the installation :+1: No issue with the ldap library so far (using the GPU Open Source db version only).
After rebuilding my database, i have noticed that high volumes queries seem to switch from GPU to CPU more quickly than before (GPU ~ 50 to 55% then switch to CPU then crashing as out of RAM). I'll get back in a separate thread if I can spot patterns in the logs.
Regards, Laurent
-
Hi @Laurent,
You aren't having issues probably because of the edition of the database you are using; the LDAP feature is for EE/Free Edition only.
There are some optimizations to improve the concurrency of the queries, but anything that should cause an increase in the memory consumption on the GPU/CPU side or cause the fragmentation of the caches.
Let me know if you are able to create a test case about it.
Regards, Candido
-
Hi Candido,
Coming back to this crash issue, I checked journalctl and found a systemd-oomd entry between the heavydb process and various kill entries:
systemd-oomd[934]: Killed /user.slice/user-1000.slice/user@1000.service/app.slice/dbus.service due to memory used (30898393088) / total (33510313984) and swap used (2006188032) / total (2147479552) being more than 90.00%
The same workload used to run just fine on Ubuntu 20.04 with a previous systemd version so hopefully a fix is under way with the next point release of Ubuntu. In the meantime, what would be your recommendation(s) to mitigate this?
Thanks, Laurent
-
HI @Laurent,
You can try to enlarge the swap memory, hoping that it can manage a transition lack of memory, can cut the size of the memory dedicated to the CPU cache, which defaults to 80% of total memory.
So as an example you can cut to 60% with the parameter
cpu-buffer-mem-bytes. Just add it to theheavyai.conf. Looking at the log your system is about 32GB so you can use 20971520000 (around 20GB). Then if using big count distinct (or skewed), you can try to cut the max memory dedicated to the operation that defaults to 8GB, and check if you can use approx_count_distinct that uses less memory (and it's less precise). The Parameter is bitmap-memory-limit and it's expressed in bytes.This should leave some room for the other OS processes and database operations that use other memory than Caches
Have you disabled the watchdog or checnged any other significant parameter?
Regrds, Candido
-
Hi Candido,
Ubuntu has just released an update that includes oomd optimization. The crash issue has disappeared, with performance on par with what it used to be on 20.04.
Thanks for the workaround, I'm sure it will be useful at some stage (to answer your question, enable-watchdog is set to false, allowed-import/export-paths are set but no other customizations in the conf file).
Regards, Laurent
Please sign in to leave a comment.
Comments
8 comments