-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High memory and CPU usage #43
Comments
Does it continue after the build stops? This is possibly caused by TabNine picking up all the filesystem events from the build. That's a lot of memory, a normal amount of usage is 500MB-1GB. Does it go back to a more reasonable level if you restart your editor or type TabNine::restart? |
I have this issue when checking out between versions while working on Python. when the versions are very different from each other I assume TabNine is rebuilding it's DB but the CPU usage is insane making my laptop almost unusable. It would be very convenient to have a CPU / RAM limit configuration |
@zxqfl Hey there! I was wondering if you have any updates on whether this is something you are working on, something you are currently fixing, or if this is more of a "no fix" kind of situation. As a paying customer, I just want to know where the author stands on this! |
Same issue here re: memory. 3G for a fairly small java/groovy project. |
EDIT: A fairly simple, though heavy, test case for both this and #24 (they seem like the same issue to me) is OpenWrt. I did a clean checkout of current master (commit
I left it hanging there since I just needed to point it to the OpenWrt directory. This gave me 100% CPU usage for eight seconds to start with, which is fair enough since it's indexing the whole directory for the first time. Memory usage stabilizes at around 300 megabytes (looking at the "RES" column in make defconfig
nice -n19 make world -j8 For some background, OpenWrt is a Linux distribution for embedded devices — routers in particular. Its build system first builds "tools", which include basic things like Of TabNine, I can observe all of the following during even just the "tools" build:
After the "toolchain" build completes, memory usage is at almost 2500 megabytes and user CPU time (as shown by In the end, the entire build took me just shy of 44 minutes. At that point TabNine's CPU time stabilized at 40 minutes and memory usage at nearly 4500 megabytes. I think it's fair to call both of these "high usage". Normally at this point I'd This time I also took a look at the number of inotify watches TabNine has registered: $ grep -c inotify /proc/27260/fdinfo/7
27118 That definitely seems incorrect. Based on this and what I saw with |
Thank you for the detailed investigation and analysis. Indeed, TabNine places a watch on every subdirectory, even those which match patterns in I guess the best way to fix this issue will be for TabNine to still use PS: You can find API documentation here. |
I reproduced the high memory usage when building OpenWrt. Today I released an update to TabNine which uses 0% CPU while building OpenWrt. The new behaviour is as follows:
The update is currently available to beta testers. To try it, type If no beta testers report issues, I'll release it to all users soon. Thanks again for investigating! |
Closing for now, please re-open if the problem persists. |
2.1.17 is consuming 3.3 GB of memory (and counting), ~35% CPU. Been running for an hour or so. |
Can confirm, tabnine 2.1.17 with vim consumes several GB if I leave it open with a few python tabs. Some of my python projects contains @zxqfl please reopen, or should I open a new bug? |
Problem is persisting with TN taking 20% of my RAM at start, and can go up to soft-locking the PC after 45 minutes or so. Fortunately my Fan runs like crazy when I'm close to 100% resources used. |
You can switch to old version which doesn't have this problem for now. This version doesn't have the CPU/MEM problem for me. |
I just checked
20GB resident memory(!) |
I'll see what I can do with VSC (sorry, not very fond of vim :p ) and keep you in touch |
I can confirm that TabNine V2.1.7 is stable on VSCode and doesn't take a whole lot of resources. |
TabNine 2.1.17 uses 1.5 GB of the memory at the initial. Is this the expected behaviour? Isn't it so much? |
using TabNine within emacs and the company package leads to an initial memory usage of 3 GB which increases over time. I now disabled the local support and try the cloud facility |
How do I downgrade to 2.1.17 with VS Code (windows WSL) |
@zxqfl could you please re-open this issue? It still seems to be a problem for a lot of people (me included). |
auto completion that took roughly 10GB when perform is not cool. will try later :) |
Indeed that is a workaround, but this is absolutely an issue within TabNine. There are numerous reports of this problem, and even after reinstalling Windows the issue persists. |
Yeah, we dont need to find a workaround, because they need to resolve this issue. And i dont understand why this issue its closed |
Is ~500mb too much for you guys ? @2020 we struggled with 1,5Gb... 500mb is fine for AI. |
500MB? I gave up on the plugin when it used > 20GB of resident RAM! |
@ilAYAli Yes! I'm running VSCode from WSL2 and i have no problem anymore with TabNine ! To be honest, I don't know if this is optimization from codata, or it's because i recently add a memory limitation to my WSL2 instance... To add memory limitation to $wsl2 :
|
@mkubdev your WSL instance is a Windows-based one? |
Hey @ilAYAli, Thank you. |
@talcodota thank you for your feedback, but I am not using the plugin anymore. |
Has this crap been resolved? I had to remove t9 from my neovim workflow because it was making the entire mac unusable. It was the newest version available. masOS 10.15.7. |
i also have the same issue. Using over 1GB of memory on my mac. |
I also have the same issue. Have to uninstall until the issue is fixed on Windows. I have advice my entire team to remove TabNine from PyCharm. We all have the same issue. |
Same here with Doom Emacs on Ubuntu, it eats all the CPU causing the editor to stutter heavily, completely unusable... |
I am using v3.5.58 on my mac and still eating 100% of the CPU during few hours of using |
Hm.... 250+ days ago I posted on this thread of now-53 participants. Sadly due to the ongoing and widespread issues I was forced to abandon TabNine. :-/ |
Same issue |
sameee issue |
Sorry for the 1 year reply lol. Yes windows based one. It's Windows Sub-System Linux. |
same issue, this is on Ubuntu 22.04 |
same, maybe tabnine needs to use GPU instead of CPU. |
on macbook pro 16 inch intel, macos version 12.6.1..it seems the same issue I use vscode... does it fixed? |
Still happening for me too.
no .gitignore for my project which currently consists of a single main.py and one folder with nothing in it. There is no good reason for this to be happening with basically no load at all on it. |
My development computer has around 8gbs, Tabnine was using around 4gbs of RAM and basically it made it crash |
I have the same Issue with Linux Debian 10, using Pycharm... Great pluggin, but kill the machine performance! |
@zxqfl can this issue be reopened? People have been having the same issue for 4 years since this was closed. |
same for me, it using cpu and memory as crazy, causing my m1 mac heating which I already forgot how is that (especially as it's not giving fan noise) it's become problem as eventually it just cause whole mac OS to crash, so yeah also disabling it, sad, helpful plugin |
Having the same issue. Whenever I start vim, memory and cpu usage shoots through the roof, causing swapping and the system crawls to a halt. It usually provides it's completions just fine and without too much overhead, but sometimes it just goes crazy. |
While working on rustc, I noticed TabNine and rls regularly consuming 100% CPU each for quite a while. I usually only notice it when I switch to a different virtual desktop when I build rustc, so it's not only while actually working in vim, but also(?) a while after I stop changing things.
Additionally, the memory usage for TabNine is huge. Currently top shows:
23316 doener 20 0 9964048 4,9g 0 S 0,0 31,2 74:41.38 TabNine
The process was started about 86 hours ago.
The text was updated successfully, but these errors were encountered: