[OmniOS-discuss] slow ssh login, maybee to many locales?

Schweiss, Chip chip at innovates.com
Mon Apr 20 16:17:03 UTC 2015


Slow ssh logon is almost always reverse DNS problems on the server side.
Adding the client to the server's /etc/hosts will usually resolve the
problem.

-Chip

On Sat, Apr 18, 2015 at 10:37 PM, PÁSZTOR György <
pasztor at sagv5.gyakg.u-szeged.hu> wrote:

> Hi,
>
> I faced with that, the login onto my new omnios zone is slow.
> I tried to debug.
> Many of the symptoms seemed pretty the same as this:
>
> http://broken.net/uncategorized/resolving-slow-ssh-login-performance-problems-on-openindiana/
>
> Also in my case it stopped at the same point: after the kexinit sent.
>
> However, on my omnios, the cryptadm list showed this:
> pasztor at omni:~$ cryptoadm list
>
> User-level providers:
> Provider: /usr/lib/security/$ISA/pkcs11_kernel.so
> Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
>
> Kernel software providers:
>         des
>         aes
>         arcfour
>         blowfish
>         ecc
>         sha1
>         sha2
>         md4
>         md5
>         rsa
>         swrand
>
> Kernel hardware providers:
> [---end of output----]
>
> So, in my case it did not contained the tpm module.
> I tried the opposite: enabling the tpm module, but nothing changed.
> (Maybe it become even slower. I did not count the seconds)
> So, I rewert it back, and run the same truss command, which revealed this:
> There are tons's of file openings in the /usr/lib/locale dir at that point:
>
> 24560:   8.8232 stat("/usr/lib/locale/is_IS.UTF-8", 0x08047D48) = 0
> 24560:   8.8234 open("/usr/lib/locale//is_IS.UTF-8/LC_CTYPE/LCL_DATA",
> O_RDONLY) = 7
> 24560:   8.8236 fstat(7, 0x08047658)                            = 0
> 24560:   8.8237 mmap(0x00000000, 94904, PROT_READ, MAP_PRIVATE, 7, 0) =
> 0xFEDE7000
> 24560:   8.8238 close(7)                                        = 0
> ...
> 24560:  14.5883
> open("/usr/lib/locale//el_GR.ISO8859-7/LC_MESSAGES/LCL_DATA", O_RDONLY) = 7
> 24560:  14.5884 fstat(7, 0x08047678)                            = 0
> 24560:  14.6061 read(7, " ^ ( ( [EDCD ] ( [E1C1 ]".., 82)       = 82
> 24560:  14.6063 close(7)                                        = 0
> 24560:  14.6065 getdents64(5, 0xFEE04000, 8192)                 = 0
> 24560:  14.6069 ioctl(1, TCGETA, 0x08046DBE)                    Err#22
> EINVAL
> 24560:  14.6069 fstat64(1, 0x08046E00)                          = 0
> 24560:  14.6070 brk(0x080689D0)                                 = 0
> 24560:  14.6071 brk(0x0806A9D0)                                 = 0
> 24560:  14.6072 fstat64(1, 0x08046D00)                          = 0
> 24560:  14.6074 close(5)                                        = 0
> 24560:  14.6075 write(1, " C\n P O S I X\n a f _ Z".., 2891)    = 2891
> 24556:  14.6076 read(3, " C\n P O S I X\n a f _ Z".., 5120)     = 2891
> 24560:  14.6077 _exit(0)
> 24556:  14.6080 brk(0x080D0488)                                 = 0
> 24556:  14.6082 brk(0x080D2488)                                 = 0
> 24556:  14.6083 read(3, 0x080CD544, 5120)                       = 0
> 24556:  14.6084 llseek(3, 0, SEEK_CUR)                          Err#29
> ESPIPE
> 24556:  14.6085 close(3)                                        = 0
> 24556:  14.6296 waitid(P_PID, 24560, 0x080473F0, WEXITED|WTRAPPED) = 0
>
> So, does somebody knows what is happening at that point,
> why,
> and how can I "fine-tune" it?
>
> Kind regards,
> György Pásztor
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20150420/50fb36e8/attachment.html>


More information about the OmniOS-discuss mailing list