Sublime Forum

100% usage all the time

#1

I am really tired of sublime text using 100% of cpu constantly.

I have moved/removed the ~/.config/sublime-text-3 and started from scratch. But it doesn’t help.

Although I had sublime open long enough for the indexing to complete, it still used 100%

/Ryan

0 Likes
Dev Build 3154
#2

Well need some more info:

  • Build
  • OS
  • Packages installed
  • Does CPU usage happen when project is closed?
0 Likes
#3

Build : 3154
OS : Ubuntu 17.10
Packages: Format_Lua, JSON_reindent, Vue syntax highlighting
Does NOT occur when project is closed.

BTW. There are build directories for buildroot/openwrt that are being indexed.

Note: After 15 hours the indexing still is running

indexing [job 4133]: indexed 4096 files
indexing [job 4133]: spawning 2 workers to process 4096 / 56475 files

0 Likes
#4

Indexing still after 15 hours sounds like it is the issue. Can you paste the entire indexer log? Is it making any progress?

Are the files mostly C?

0 Likes
#5

Ok. It was kinda behaving yesterday. This morning it is not.

  • The indexing seems to be done. There are not any new jobs being spawned.
0 Likes
#6

Build no: 3155

Yes, files are mostly C.

It was behaving yeseterday. This morning (the system was on all night), it is misbehaving.

  • Indexing seems to done. There are no new processes being spawned
    indexing [job 29]: indexed 3 files
    indexing [job 30]: spawning 1 workers to process 3 / 3 files
    indexing [job 30]: indexed 3 files

The job stays at 30.

  • There seems to be only one thread running (sublime_text) and it is running at 100%.
    A quick strace shows…

clock_gettime(CLOCK_BOOTTIME, {tv_sec=74681, tv_nsec=423296537}) = 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=74681, tv_nsec=423332872}) = 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=74681, tv_nsec=423359777}) = 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=74681, tv_nsec=423387793}) = 0
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=20, events=POLLIN}, {fd=114, events=POLLIN}, {fd=125, events=POLLIN}, {fd=126, events=POLLIN}, {fd=127, events=POLLIN}, {fd=128, events=POLLIN}, {fd=129, events=POLLIN}, {fd=130, events=POLLIN}, {fd=131, events=POLLIN}, {fd=132, events=POLLIN}, {fd=133, events=POLLIN}, {fd=134, events=POLLIN}], 18, 0) = 0 (Timeout)
recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=20, events=POLLIN}, {fd=114, events=POLLIN}, {fd=125, events=POLLIN}, {fd=126, events=POLLIN}, {fd=127, events=POLLIN}, {fd=128, events=POLLIN}, {fd=129, events=POLLIN}, {fd=130, events=POLLIN}, {fd=131, events=POLLIN}, {fd=132, events=POLLIN}, {fd=133, events=POLLIN}, {fd=134, events=POLLIN}], 18, 0) = 0 (Timeout)

Again, and again, etc.

I am running

ps -e -T | grep sublime
13922 13922 ? 00:44:08 sublime_text
13922 14002 ? 00:00:01 sublime_text

intermittent threads are spawned and done.

1 Like
#7

Using a more specific strace expression (strace -e trace=open,read) yields
…
read(5, “\0”, 1) = 1
read(5, “\0”, 1) = 1
read(132, “\10\5\0\0\2\0\0\0\0\0\0\0 \0\0\0mozilla-temp-214”…, 65536) = 48
read(5, “\0”, 1) = 1
read(132, “\10\5\0\0\2\0\0\0\0\0\0\0 \0\0\0mozilla-temp-214”…, 65536) = 48
read(5, “\0”, 1) = 1
…

1 Like
#8

I recently noticed Sublime 3 Build 3143 hitting 100% CPU usage on Mac OS 10.13.1 and gobbling up several gigabytes of RAM, culminating in the Force Quit option being offered by the OS as it informed me the machine had run out of memory. I narrowed this behaviour down to Sublime’s defaulting to an anonymous project that was apparently starting from / and attempting to index the entire disk, which is very unusual because using Sublime without an explicitly defined project has always been extremely quick and responsive. Creating a project to limit the scope of the indexing to the files I was working on fixed the problem, at least in this situation.

0 Likes
#9

I had the same problem and also I tried to reinstall a fresh copy without plugins, etc. Finally, I solved it by setting “gpu_window_buffer”: to false in preferences. No more high CPU usage.

1 Like