npm is very slow on Windows 10 - node.js

This question is basically a duplicate of this one, except that the accepted answer on that question was, "it's not actually slower, you just weren't running the timing command correctly."
In my case, it actually is slower! :)
I'm on Windows 10. Here's the output from PowerShell's Measure-Command (the TotalMilliseconds line represents wall-clock time):
PS> Measure-Command {npm --version}
Days : 0
Hours : 0
Minutes : 0
Seconds : 1
Milliseconds : 481
Ticks : 14815261
TotalDays : 1.71472928240741E-05
TotalHours : 0.000411535027777778
TotalMinutes : 0.0246921016666667
TotalSeconds : 1.4815261
TotalMilliseconds : 1481.5261
A few other numbers, for comparison:
'{.\node_modules.bin\mocha}': 1300ms
'npm run test' (just runs mocha): 3300ms
npm help: 1900ms.
the node interpreter itself is ok: node -e 0: 180ms
It's not just npm that's slow... mocha reports that my tests only take 42ms, but as you can see above, it takes 1300ms for mocha to run those 42ms of tests!

I've had the same trouble. Do you have Symantec Endpoint Protection? Try disabling Application and Device Control in Change Settings > Client Management > General > Enable Application and Device Control.
(You could disable SEP altogether; for me the command is: "%ProgramFiles(x86)%\Symantec\Symantec Endpoint Protection\smc.exe" -stop.)
If you have some other anti-virus, there's likely a way to disable it as well. Note that closing the app in the Notification area might not stop the virus protection. The problem is likely with any kind of realtime protection that scans a process as it starts. Since node and git are frequently-invoked short-running processes, this delay is much more noticeable.
In Powershell, I like to measure the performance of git status, both before and after that change: Measure-Command { git status }

I ran into this problem long ago, I think it was an extension that I had. I use Visual Studio Code, and when it has no extensions and running bash:
//GIT Bash Configuration
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
it actually flies, I use both OS, so I can tell the difference. Try using different tools and disabling some.
And if that still doesn't work, check your antivirus, maybe it's slowing down the process?

Been googling this all day, with no luck. Decided to uninstall Java to see what would happen and bingo, solved my problem. I know this is an old thread, but I found myself coming back to it so many times to see if I missed anything.
off topic:
Got to figure out how to get Java working now 🤦
Didn't know about Measure-Command, so I'll be using that in the future!

I had this problem. When I tried to run an application of my job in my home, I realized that in my job's laptop the app starts on 2 minutes but in my personal notebook it tooked 5 minutes or more.
After trying some possible solutions, finally I found the problem was that I installed Git Bash in my D drive partition which is a HDD. When I re-installed in C drive whichs is a SSD then the app started faster. However, I also moved Node.js to C drive to prevent another issues.

Related

Print to PDF by browser take a lot of threads?

I tried Brave on Mac with the command in the answer by K J in the following question. But after running many such conversions, I may end up with a message of -bash: fork: retry: Resource temporarily unavailable in a terminal. It seems that too many threads are used and not cleaned afterward. What is going wrong here?
How to use brave to automate printing html to pdf?
Ok I guess this may not be normal type of answer as its kind of "works for me"
In cases such as this where the "programming" is simply one cross platform command, that in its dependencies uses system and application resources, there are times one user has problems and others do not. Thus debugging can be highly system dependent.
By way of explanation as to potential issues (and its too long for simple comments) here are my experiences on Windows.
pre running (why so many windows processes !!)
Fresh boot
Apps=3
one is system folder explorer
one is this notepad
one is task manager monitor
Background processes=82 Including Edge (inactive=5 !!)
processes=107 including console = 5 !!
Start command terminal
Apps =+1 with 3 sub processes ?
Background =+1 command prompt
processes =+1 (console now = 6)
Start Brave portable
apps =+1 Brave no page requested only welcome but with 8 sub processes !#?
background =+1 brave portable
processes =same (console still = 6)
Navigate to this page
apps = same Brave with this page requested = 9 then drops back to 8 sub processes !
background = same 1 brave portable
processes =same (console still = 6)
Run 20 similar commands with/without --enable-logging
Mea Culpa (Idiot) 20 fails several times because I did not verify if will run without a running Brave nor test bad cut and paste
but looks like no residual change to processes ??
Try again with brave closed
Apps and Background processes returns to before Brave active
for /l %a in (1,1,20) do brave-portable --headless --print-to-pdf="C:\Users\K\Downloads\brave-portable\test2-%a.pdf" --disable-extensions --print-to-pdf-no-header --disable-popup-blocking --run-all-compositor-stages-before-draw --disable-checker-imaging "https://stackoverflow.com/questions/74788259/how-to-use-brave-to-automate-printing-html-to-pdf"
Hmmm without error checking there is some noticed difference to an earlier run
call completes in a few seconds thus its much too quick to see tasks listed in manager.
Background processes ramped up to 194 !! before drop back to about 78
and after about 20 seconds there are 19 same size files (as almost might be expected)
Now what is odd about that is that usually from experience they should all be different sizes as each call should show different in-page adverts over time
but then again I had logged in and accepted cookies earlier, so there should be no ads to make a difference in later runs.
EXCEPT ONE rogue file out of 20 has an advert Arghhhhhhhh!!
so the inconsistencies saga continues.
However there is no residual use of task processes in my Windows portable Brave with that command sequence!
On its own Brave is using only a few percent of CPU and Memory before and after with no hint of tying up disk or other resource features.

CentOS 8 dbus-daemon stops selinux enforcing for a few minutes then returns to enforcing

I am having a problem I have spent multiple days searching for an answer to. I administer a system running CentOS 8 (yes, I know, move to another distribution - we are within the month). The problem I am having is that if I do an "ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today" I find that the system's dbus-daemon is found to do this: "msg='avc: received setenforce notice (enforcing=0) exe="/usr/bin/dbus-daemon"". A few minutes later (like 2 and a half minutes), the daemon does this: " msg='avc: received setenforce notice (enforcing=1) exe="/usr/bin/dbus-daemon"".
I cannot find any references on the net to any daemon that does this and it concerns me that it may be a security failure of which our company does the best it can to eliminate. Can anyone enlighten me as to what is happening?

How to investigate which process causes wakeups during laptop sleep-mode in MacOS (or Linux)?

My MacBook spontaneously wakes up from sleep mode with high fan activity.
I want to do a investigate this in RTC or power settings? Or by strace-ing of processes, etc (using some process/kernel magic!).
Hint: It is probably managed by "rtcwake".
I am not even sure if this is a scheduled task, or from a WiFi wakeup, or something else.
I don't want guesses about what usually causes this in Mojave, etc. Instead:
I need to do a systematic investigation on this on my MacOS (Mojave). Linux-related answers are also appreciated.
This is about system standby, sleep-mode, suspended mode. (Note that this is not about standup and wakeup of individual processes. The whole laptop turns on spontaneously.)
Reading the log file is the best way to debug the problem.
So, try this command in your Terminal to fetch the system logs,
this will tell you "wake up" history.
log show --style syslog | fgrep "Wake reason: EC.LidOpen"
To see the wake reason:
For macOS Sierra, Mojave, Catalina, and newer
log show |grep -i "Wake reason"
Or for MacOS El Capitan, Yosemite, Mavericks, and older
syslog |grep -i "Wake reason"
This will look like:
MacBookPro kernel[0] : Wake reason = OHC1
MacBookPro kernel[0] : Wake reason = PWRB
MacBookPro kernel[0] : Wake reason = EHC2
MacBookPro kernel[0] : Wake reason = OHC1
So what do these wake reason codes mean?
OHC: stands for Open Host Controller, is usually USB or Firewire. If you see OHC1 or OHC2 it is almost certainly an external USB keyboard or mouse that has woken up the machine.
EHC: standing for Enhanced Host Controller, is another USB interface, but can also be wireless devices and bluetooth since they are also on the USB bus of a Mac.
USB: a USB device woke the machine up
LID0: this is literally the lid of your MacBook or MacBook Pro when you open the lid the machine wakes up from sleep.
PWRB: PWRB stands for Power Button, which is the physical power button on your Mac
RTC: Real Time Clock Alarm, is generally from wake-on-demand services like when you schedule sleep and wake on a Mac via the Energy Saver control panel. It can also be from launchd setting, user applications, backups, and other scheduled events.
There may be some other codes (like PCI, GEGE, etc) but the above are the ones that most people will encounter in the system logs. Once you find out these codes, you can really narrow down what is causing your Mac to wake up from sleep seemingly at random.
Hope this will help :)
This answer is based on Linux, so it might not apply strictly to Mac.
To determine whether rtcwake is responsible for your MacOS wakeups, you could replace the executable (in my Ubutnu it is /usr/sbin/rtcwake) with a wrapper script that leaves a sign of rtcwake having run, e.g.
$ cd /usr/sbin/rtcwake
$ sudo mv rtcwake rtcwake_orig
and then write script /usr/sbin/rtcwake containing
#!/bin/bash
touch $HOME/rtcwake_ran
/usr/sbin/rtcwake_orig
Variants of the script would depend on your shell.
In particular, in the last line you would possibly run rtcwake in some alternative way, so as to not own the process (nohup / disown).
See https://unix.stackexchange.com/questions/152310/how-to-correctly-start-an-application-from-a-shell
To inspect possible causes of wakeup, you can check various relevant logs, at /var/log.
E.g., syslog*, acpi*.
See also https://unix.stackexchange.com/questions/83036/where-is-the-log-for-acpi-events
Do you have wakeonlan?
Here I am documenting my systematic approach. It is loosely based on, and initiated by, the answer by #vijay-rajpurohit, which is in turn based on comment by #Robert #1431720 . Note that the final result is particular to my MacOS machine, based on the logs shown below. It will be different in your MacOS.
In first attempt, I first checked the logs using: log show --style syslog | grep ... but it is taking too long. I accidentally checked /var/log/wifi.log after exploring the /var/log/ (I am also curious about /var/log/powermanagement/*.asl).
This turned out to be most useful:
cat /var/log/wifi.log|grep -i "Wake reason"
Then found this line: (note the EC. bit)
Thu Apr 23 22:41:32.359 Info: <airportd[219]> _systemWokenByWiFi: System wake reason: <EC.ARPT>, was woken by WiFi
Then googled for EC.ARPT, I found the following commands:
pmset -g log Useful stats about "Total Sleep/Wakes since boot".
pmset -g assertions This turned out to show the full answer to this question:
2020-04-24 02:23:38 +0100
Assertion status system-wide:
BackgroundTask 1
ApplePushServiceTask 0
UserIsActive 1
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
ExternalMedia 0
PreventUserIdleSystemSleep 0
NetworkClientActive 0
Listed by owning process:
pid 111(hidd): [0x0000200a000986a9] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle.4295010950.3"
pid 85(apsd): [0x0003b830000b90bd] 00:00:10 ApplePushServiceTask named: "com.apple.apsd-waitingformessages-push.apple.com"
Kernel Assertions: 0x100=MAGICWAKE
id=504 level=255 0x100=MAGICWAKE mod=24/04/2020, 01:57 description=en0 owner=en0
Idle sleep preventers: IODisplayWrangler
In short, in a systematic approach, I explored the following keywords based on the logs, and googled each :
EC.ARPT (example link)
iohideventsystem (example link)
MAGICWAKE (example link)
ApplePushServiceTask (see below)
Most informative item emerged from the output of pmset -g assertions. For example ApplePushServiceTask in the following line:
pid 85(apsd): [0x0003b830000b90bd] 00:00:10 ApplePushServiceTask named: "com.apple.apsd-waitingformessages-push.apple.com"
The solution that seems to work in my particular case (not a general solution) was to disable :
/System/Library/LaunchDaemons/com.apple.apsd.plist using launchctl. But this cannot be done until you do a csrutil disable in the safe mode. I don't write instructions here because it need caution and you need to enable it later.
(to be updated)

Forever logs keep growing

I run the NPM global module Forever on my Node server (on Azure). Always works fine to keep all my projects running.
There is 1 project on my server that perhaps has an issue or something that causes Forever to keep outputting to the log. There are 2 Forever logs that grow rapidly and to huge sizes:
9.7Gb /home/azureuser/.forever/P_lf.log
1.3Gb /home/azureuser/.forever/IEJR.log
Whilst I probably need to find out what's wrong with my project and fix it, I also need to fix this logging problem. My research shows I may need to do something with logrotate to stop this much disk space being used.
Any ideas?
There are 2 moments:
You can edit Your app to log only necessary things and errors (can catch errors to prevent them), so Your logs will be smaller.
You can set cron job to cleanup log files every night (let's say every 03:00 AM):
0 3 * * * truncate -s 0 /home/azureuser/.forever/*.log
or odd days (to be able to keep logs one day for debug purposes):
0 3 * * 1,3,5 truncate -s 0 /home/azureuser/.forever/*.log

Bitcoind reindex taking too long. How do I troubleshoot?

I'm trying to get a fully indexed transaction history in bitcoin on my local machine in order to query specific "foreign" transactions. As instructed, I've set txindex=1 in /home/me/.bitcoin/bitcoin.conf, which now reads:
rpcpassword=mypass
txindex=1
I run "bitcoind -reindex" in the terminal and it processes and processes.... and processes. I can see that it's using some system resources through "ps aux | grep bit" but the process never seems to die. I let it run for over a week and it never seemed to finish.
I've seen other people report reindexing with the txindex on only taking a matter of hours, so I'm at a loss to figure out what is going on. I thought maybe that the bitcoind -reindex was just not resulting in an exit code since, after all, it's a daemon that's supposed to run all the time. But when I stopped it and restarted it (without the "reindex" flag), I still get errors if I run "getrawtransaction XXXX" on old transactions.
I'm running ubuntu linux. Is there a way I can monitor the reindex process to see how long it's going to take? Am I doing something wrong that it should take so much time to reindex? Am I doing something wrong in general?
Appreciate any help.
You can check the status with this command:
bitcoin-cli getblockchaininfo
bitcoin#alfa:~/.bitcoin/blocks$ bitcoin-cli getblockchaininfo
{
"chain" : "main",
"blocks" : 156942,
"headers" : 156942,
"bestblockhash" : "00000000000005ae04a5657be198c038a87bee8b8cdc51ff079536493c887ba9",
"difficulty" : 1090715.68005127,
"verificationprogress" : 0.00897010,
"chainwork" : "000000000000000000000000000000000000000000000009fd73b127af545deb",
"pruned" : false,
"softforks" : [
{
[...]
More info about bitcoin-cli can be found at: https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs

Resources